Thread: Re: [PATCHES] S_LOCK reduced contention through backoff patch

Re: [PATCHES] S_LOCK reduced contention through backoff patch

From
dg@illustra.com (David Gould)
Date:
> On Tue, 28 Apr 1998, David Gould wrote:
> > After a long wait (as I was busy with other things), here is the Spinlock
> > back off patch I promised. This does semi-random backoff using select() to
> > lessen throughput degradation due to spinlock contention with large numbers
> > of runnable backends.
> >
> > This patch is meant to work on all current platforms, but I have only tested
> > it on Linux 2.0.32 i386 glibc (Redhat 5.0).
>
> Hi David...
>
>     Just tried to apply this to the current source tree, and pretty
> much failed miserably :(  can you check it and let me know?
>


"Hey Rocky, watch me submit a patch to pgsql. This time for sure".

Actually, I took the opportunity to think about it overnight and add a
few frills.

I just sent the patch (in diff -c format this time)
the patches list. I am reproducing the blurb here.

It should apply cleanly to 6.3.2 and the current snapshot.

Here is the Spinlock back off patch I promised. This does semi-random
backoff using select() to lessen throughput degradation due to spinlock
contention with large numbers of runnable backends.

This patch is meant to work on all current platforms, but I have only tested
it on Linux 2.0.32 i386 glibc (Redhat 5.0).

I restructured the files s_lock.c and s_lock.h to better separate the portable
parts from the machine dependant parts. Probably the best way to see what
happened is to apply the patch and then look at the changed files rather than
to try to read the patch directly.

I have also added a timeout feature to the attempt to grab a spinlock. If after
a suitably long time (currently a few minutes) a lock still cannot be locked,
we printf() a message and abort() the backend.

I hope that I have preserved the correctness of the tas() assembly code, but
this needs to be tested on each platform to make sure I have the sense of
the tests right. Remember, tas() is test_and_set and returns the PRIOR STATE
of the lock. If the prior state was FREE, the caller of TAS is now the lock
owner. Otherwise, the lock was already locked by someone else.

To make it easier to test on each platform, I have added a test routine and
makefile target to verify the S_LOCK() functionality. To run this:

If not done already
   cd pgsql
   apply patch
   run configure
and then
   cd src/backend/buffer
   make s_lock_test

If the test appears to hang (or you end up after a few minutes with the
"Stuck Spinlock" message), then S_LOCK() is working. Otherwise, please have
a look at what TAS() is returning and either fix it for the platform, or let
me know and I will give it a whack.

Let me know if there are any problems or questions.
-dg


David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
"(Windows NT) version 5.0 will build on a proven system architecture
 and incorporate tens of thousands of bug fixes from version 4.0."
                 -- <http://www.microsoft.com/y2k.asp?A=7&B=5>

Re: [HACKERS] Re: [PATCHES] S_LOCK reduced contention through backoff patch

From
ocie@paracel.com
Date:
David Gould wrote:

[snip]
> Here is the Spinlock back off patch I promised. This does semi-random
> backoff using select() to lessen throughput degradation due to spinlock
> contention with large numbers of runnable backends.

Does this actually use some sort of random number generator?  I'm
thinking that this may not be entirely necessary.  With Ethernet, this
is needed to avoid another colission, but with locks, one process is
guaranteed to get a lock.

Ocie

Re: [HACKERS] Re: [PATCHES] S_LOCK reduced contention through backoff patch

From
Bruce Momjian
Date:
>
> David Gould wrote:
>
> [snip]
> > Here is the Spinlock back off patch I promised. This does semi-random
> > backoff using select() to lessen throughput degradation due to spinlock
> > contention with large numbers of runnable backends.
>
> Does this actually use some sort of random number generator?  I'm
> thinking that this may not be entirely necessary.  With Ethernet, this
> is needed to avoid another colission, but with locks, one process is
> guaranteed to get a lock.

From the patch.  Looks very good to me.

!  * Each time we busy spin we select the next element of this array as the
!  * number of microseconds to wait. This accomplishes pseudo random back-off.
!  * Values are not critical and are weighted to the low end of the range. They
!  * were chosen to work even with different select() timer resolutions on
!  * different platforms.
!  * note: total time to cycle through all 16 entries might be about .1 second.
!  */
! int                   s_spincycle[S_NSPINCYCLE] =
! {0, 0, 0, 1000, 5000, 0, 10000, 3000,
!  0, 10000, 0, 15000, 9000, 21000, 6000, 30000
! };

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Re: [HACKERS] Re: [PATCHES] S_LOCK reduced contention through backoff patch

From
dg@illustra.com (David Gould)
Date:
Ocie:
> David Gould wrote:
>
> [snip]
> > Here is the Spinlock back off patch I promised. This does semi-random
> > backoff using select() to lessen throughput degradation due to spinlock
> > contention with large numbers of runnable backends.
>
> Does this actually use some sort of random number generator?  I'm

No. Have a look at the patch.

> thinking that this may not be entirely necessary.  With Ethernet, this
> is needed to avoid another colission, but with locks, one process is
> guaranteed to get a lock.

In the case where this comes into play, one process already has the lock.
We have already collided. We are trying to limit the number of additional
collisions.

-dg


David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
"(Windows NT) version 5.0 will build on a proven system architecture
 and incorporate tens of thousands of bug fixes from version 4.0."
                 -- <http://www.microsoft.com/y2k.asp?A=7&B=5>