Skip site navigation (1) Skip section navigation (2)

Re: Wierd context-switching issue on Xeon

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pg(at)fastcrypt(dot)com,Robert Creager <Robert_Creager(at)LogicalChaos(dot)org>,Josh Berkus <josh(at)agliodbs(dot)com>, Dirk_Lutzebäck <lutzeb(at)aeccom(dot)com>,ohp(at)pyrenet(dot)fr, Joe Conway <mail(at)joeconway(dot)com>,"scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>,pgsql-performance(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: Wierd context-switching issue on Xeon
Date: 2004-05-20 02:41:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2004-05-20 02:42:26
Subject: Re: Wierd context-switching issue on Xeon
Previous:From: Robert CreagerDate: 2004-05-20 01:59:26
Subject: Re: Wierd context-switching issue on Xeon

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group