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

Re: Wierd context-switching issue on Xeon patch for 7.4.1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pg(at)fastcrypt(dot)com
Cc: Paul Tuckfield <paul(at)tuckfield(dot)com>,Anjan Dave <adave(at)vantage(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>,Neil Conway <neilc(at)samurai(dot)com>,Dirk Lutzeb├Ąck <lutzeb(at)aeccom(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: Wierd context-switching issue on Xeon patch for 7.4.1
Date: 2004-04-22 12:36:28
Message-ID: 25058.1082637388@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> My hypothesis is that if you spin approximately the same or more time
> than the average time it takes to get finished with the shared resource
> then this should reduce cs.

The only thing we use spinlocks for nowadays is to protect LWLocks, so
the "average time" involved is fairly small and stable --- or at least
that was the design intention.  What we seem to be seeing is that on SMP
machines, cache coherency issues cause the TAS step itself to be
expensive and variable.  However, in the experiments I did, strace'ing
showed that actual spin timeouts (manifested by the execution of a
delaying select()) weren't actually that common; the big source of
context switches is semop(), which indicates contention at the LWLock
level rather than the spinlock level.  So while tuning the spinlock
limit count might be a useful thing to do in general, I think it will
have only negligible impact on the particular problems we're discussing
in this thread.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Eduardo AlmeidaDate: 2004-04-22 12:53:18
Subject: Re: [PERFORM] MySQL vs PG TPC-H benchmarks
Previous:From: Michiel MeeuwissenDate: 2004-04-22 11:02:14
Subject: Re: order by index, and inheritance

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