Yeah, I did some more testing myself, and actually get better numbers
with increasing spins per delay to 1000, but my suspicion is that it is
highly dependent on finding the right delay for the processor you are
on.
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.
Certainly more ideas are required here.
Dave
On Wed, 2004-04-21 at 22:35, Tom Lane wrote:
> 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
>
>
>
> !DSPAM:40872f7e21492906114513!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561