Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pg@fastcrypt.com
Cc: Paul Tuckfield <paul@tuckfield.com>, Anjan Dave <adave@vantage.com>, Josh Berkus <josh@agliodbs.com>, Neil Conway <neilc@samurai.com>, Dirk Lutzebäck <lutzeb@aeccom.com>, pgsql-performance@postgresql.org
Date: 2004-04-22T02:35:30Z
Lists: pgsql-performance 
Dave Cramer <pg@fastcrypt.com> writes:
> diff -c -r1.16 s_lock.c
> *** backend/storage/lmgr/s_lock.c	8 Aug 2003 21:42:00 -0000	1.16
> --- backend/storage/lmgr/s_lock.c	21 Apr 2004 20:27:34 -0000
> ***************
> *** 76,82 ****
>   	 * The select() delays are measured in centiseconds (0.01 sec) because 10
>   	 * msec is a common resolution limit at the OS level.
>   	 */
> ! #define SPINS_PER_DELAY		100
>   #define NUM_DELAYS			1000
>   #define MIN_DELAY_CSEC		1
>   #define MAX_DELAY_CSEC		100
> --- 76,82 ----
>   	 * The select() delays are measured in centiseconds (0.01 sec) because 10
>   	 * msec is a common resolution limit at the OS level.
>   	 */
> ! #define SPINS_PER_DELAY		10
>   #define NUM_DELAYS			1000
>   #define MIN_DELAY_CSEC		1
>   #define MAX_DELAY_CSEC		100


As far as I can tell, this does reduce the rate of semop's
significantly, but it does so by bringing the overall processing rate
to a crawl :-(.  I see 97% CPU idle time when using this patch.
I believe what is happening is that the select() delay in s_lock.c is
being hit frequently because the spin loop isn't allowed to run long
enough to let the other processor get out of the spinlock.

			regards, tom lane