| 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: | 24373.1085020886@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-05-20 02:42:26 | Re: Wierd context-switching issue on Xeon |
| Previous Message | Robert Creager | 2004-05-20 01:59:26 | Re: Wierd context-switching issue on Xeon |