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 -
individualthreads 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
scheduledimmediately, 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
asdescribed above
So would it be possible for you to record resource consumption and rerun the test?
Thank you, Nils