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

From Nils Goroll
Subject Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux
Date
Msg-id 4FF09EAD.6080902@schokola.de
Whole thread Raw
In response to Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [ADMIN] pg_basebackup blocking all queries with horrible performance
Next
From: Hans-Jürgen Schönig
Date:
Subject: Re: [PATCH] Make pg_basebackup configure and start standby