[2002-01-05 14:01] Tom Lane said:
| Brent Verner <brent@rcfile.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
