Hi Robert,
> Spinlock contentions cause tps to go down. The fact that tps didn't
> change much in this case suggests that either these workloads don't
> generate enough spinlock contention to benefit from your patch, or
> your patch doesn't meaningfully reduce it, or both. We might need a
> test case that is more spinlock-bound to observe an effect.
Agree. My understanding is that
- for no contention, aquiring a futex should almost be as fast as aquiring a
spinlock, so we should observe
- comparable tps
- comparable resource consumption
I believe this is what your test has shown for the low concurrency tests.
- for light contention, spinning will be faster than syscalling, so
we should observe with the patch
- slightly worse tps
- more syscalls, otherwise comparable resource consumption
I believe your test supports the first point for high concurrency tests.
- for high contention, spinning should be be
- unfair (because the time to aquire a lock is not deterministic -
individual threads could starve)
- much less efficient
and we should see with the patch
- slightly better tps if the system is not saturated because
the next process to aquire a contended futex gets scheduled immediately,
rather than when a process returns from sleeping
- much better tps if the system is saturated / oversubscribed due to
increased scheduling latency for spinning processes
- significantly lower resource consumption
- so we should have much more headroom before running into saturation
as described above
So would it be possible for you to record resource consumption and rerun the
test?
Thank you, Nils
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
