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

In response to

• Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux at 2012-07-01 18:25:25 from Robert Haas

pgsql-hackers by date

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