From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brent Verner <brent(at)rcfile(dot)org> |
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-06 03:05:51 |
Message-ID: | 23177.1010286351@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Brent Verner <brent(at)rcfile(dot)org> writes:
> | What I should've thought of is to try sched_yield() as well, which is
> | the operation we *really* want here, and it is available on this version
> | of Linux. Off to run another batch of tests ...
> yes. using just sched_yield() inside the TAS loop appears to give
> better performance on both freebsd and linux (single-proc); in
> particular, it _looks_ like there is a 8-10% performance gain at
> 32 clients.
I'm noticing more variability in the results today than I got yesterday;
this is odd, since the only change in the system environment is that we
cleaned off some more free space on the disk drive array in preparation
for running larger benchmarks. An example of the variability can be
seen by comparing the two "yield spins 100" curves below, which should
be identical circumstances. Still, it's clear that using sched_yield
is a win.
Also note that spins=1000 seems to be a loser compared to spins=100 when
using sched_yield, while it is not with either select or usleep. This
makes sense, since the reason for not wanting to yield the processor
is the large delay till we can run again. With sched_yield that penalty
is eliminated.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
![]() |
image/gif | 8.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-01-06 04:32:28 | pgbench, consistency? |
Previous Message | guard | 2002-01-06 02:32:43 | postgresql 7.2b4 bug |