Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux

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