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
