Re: Some interesting results from tweaking spinlocks

From: Brent Verner <brent(at)rcfile(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Some interesting results from tweaking spinlocks
Date: 2002-01-05 21:41:01
Message-ID: 20020105214101.GA7357@rcfile.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[2002-01-05 14:01] Tom Lane said:
| Brent Verner <brent(at)rcfile(dot)org> writes:
| > I suspect using usleep() instead of select() might
| > relieve the serialization.
|
| A number of people have suggested that reducing the sleep interval would
| improve matters.

Using a single-processor machine, we're not going to get any lower
sleep times than ~10ms from either usleep or select on linux, and
usleep is always longer.

brent$ ./s_lock 1 0
usleep = 0.007130 s
select = 0.000007 s
nanosleep = 0.013286 s
brent$ ./s_lock 1 10
usleep = 0.013465 s
select = 0.009879 s
nanosleep = 0.019924 s

On FBSD, the shortest sleep is ~20ms, but is the same for usleep and
select.

| I tried that just now, again on RedHat's 4-way box,
| and was mildly astonished to find that it makes things worse. The graph
| below shows pgbench results for both the current code (10 millisec delay
| using select()) and a 10-microsec delay using usleep(), with several
| different SPINS_PER_DELAY values. Test conditions are otherwise the
| same as in my last message (in particular, LWLock patch version 2).

Ah, now this is very interesting. Looks like increasing spins allows
the process to get the lock before the usleep/select is run -- based
on the fact the that "usleep 10 spins 100" is markedly lower than the
select version. This is in keeping with observation mentioned above
where usleep sleeps longer than select() on linux.

It would be interesting to count the number of times this select() is
called on the SMP machines at various spin counts.

| At any given SPINS_PER_DELAY, the 10msec sleep beats the 10usec sleep
| handily. I wonder if this indicates a problem with Linux'
| implementation of usleep?

I don't think so, but it does disprove my original suspicion. Given
the significant performance gap, I'd vote to add a configurable
parameter for the spin counter.

thanks.
brent

--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-01-05 21:44:53 Re: LWLock contention: I think I understand the problem
Previous Message Tom Lane 2002-01-05 21:39:31 Re: pgcryto strangeness...