I wrote:
> No I/O anywhere. I'm thinking the reported idle time must correspond to
> spinlock delays that are long enough to reach the select() calls in
> s_lock. If so, 38% is depressingly high, but it's not out of line with
> what we've seen in the past in tests designed to provoke spinlock
> contention.
I tried increasing MAX_SPINS_PER_DELAY from 1000 to 10000. (Again, this
is with the unlocked test added to TAS_SPIN.) This resulted in a very
significant drop in the reported idle-time percentage, down to 10% or so
at full load; but unfortunately the TPS numbers got worse for the higher
end of the curve:
pgbench -c 1 -j 1 -S -T 300 bench tps = 4526.914824 (including ...
pgbench -c 2 -j 1 -S -T 300 bench tps = 8183.815526 (including ...
pgbench -c 8 -j 4 -S -T 300 bench tps = 34637.075173 (including ...
pgbench -c 16 -j 8 -S -T 300 bench tps = 68792.550304 (including ...
pgbench -c 32 -j 16 -S -T 300 bench tps = 159195.038317 (including ...
pgbench -c 64 -j 32 -S -T 300 bench tps = 220544.912947 (including ...
pgbench -c 96 -j 48 -S -T 300 bench tps = 147367.793544 (including ...
pgbench -c 128 -j 64 -S -T 300 bench tps = 79187.042252 (including ...
pgbench -c 160 -j 80 -S -T 300 bench tps = 43957.912879 (including ...
So that confirms the idea that the reported idle time corresponds to
s_lock select() sleeps. Unfortunately, it doesn't appear to lead to
anything that would result in increasing performance. I suppose the
reason that performance gets worse, even though we've presumably
eliminated some process context swaps, is that we have more cache line
contention for whichever spinlock(s) they're all fighting over.
regards, tom lane
