Horton

Re: Wierd context-switching issue on Xeon

Bruce Momjian <pgman@candle.pha.pa.us>

View thread
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pg@fastcrypt.com, Robert Creager <Robert_Creager@LogicalChaos.org>, Josh Berkus <josh@agliodbs.com>, Dirk_Lutzebäck <lutzeb@aeccom.com>, ohp@pyrenet.fr, Joe Conway <mail@joeconway.com>, "scott.marlowe" <scott.marlowe@ihs.com>, pgsql-performance@postgresql.org, Neil Conway <neilc@samurai.com>
Date: 2004-05-20T03:02:16Z
Lists: pgsql-performance 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Did we ever come to a conclusion about excessive SMP context switching
> > under load?
> 
> Yeah: it's bad.
> 
> Oh, you wanted a fix?  That seems harder :-(.  AFAICS we need a redesign
> that causes less load on the BufMgrLock.  However, the traditional
> solution to too-much-contention-for-a-lock is to break up the locked
> data structure into finer-grained units, which means *more* lock
> operations in total.  Normally you expect that the finer-grained lock
> units will mean less contention.  But given that the issue here seems to
> be trading physical ownership of the lock's cache line back and forth,
> I'm afraid that the traditional approach would actually make things
> worse.  The SMP issue seems to be not with whether there is
> instantaneous contention for the locked datastructure, but with the cost
> of making it possible for processor B to acquire a lock recently held by
> processor A.

I see.  I don't even see a TODO in there.  :-(

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073