Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1573371

Re: [PATCH-tip v5 17/21] TP-futex: Group readers together in wait queue

Show all headers | View raw

On 02/03/2017 01:23 PM, valdis.kletnieks@vt.edu wrote:
> On Fri, 03 Feb 2017 13:03:50 -0500, Waiman Long said:
>
>> On a 2-socket 36-core E5-2699 v3 system (HT off) running on a 4.10
>>                           WW futex       TP futex         Glibc
>>                           --------       --------         -----
>> Total locking ops        35,707,234     58,645,434     10,930,422
>> Per-thread avg/sec           99,149        162,887         30,362
>> Per-thread min/sec           93,190         38,641         29,872
>> Per-thread max/sec          104,213        225,983         30,708
> Do we understand where the 38K number came from?  I'm a bit concerned that the
> min-to-max has such a large dispersion compared to all the other numbers.  Was
> that a worst-case issue, and is the worst-case something likely to happen in
> production, or requires special effort to trigger?
>
Because the lock isn't fair and depending on the placement of the lock,
you will see some CPUs have higher likelihood of getting the lock than
the others. This is reflected in the different locking rates as reported
by the micro-benchmark.  As the microbenchmark is included in this patch
set, you can play around with it if you want.

This patch set does guarantee some minimum performance level, but it
can't guarantee fairness for all the lock waiters.

Regards,
Longman

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH-tip v5 00/21] futex: Introducing throughput-optimized (TP) futexes Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
  [PATCH-tip v5 20/21] sched, TP-futex: Make wake_up_q() return wakeup count Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
  [PATCH-tip v5 21/21] futex: Dump internal futex state via debugfs Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
  [PATCH-tip v5 17/21] TP-futex: Group readers together in wait queue Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
    Re: [PATCH-tip v5 17/21] TP-futex: Group readers together in wait queue valdis.kletnieks@vt.edu - 2017-02-03 19:30 +0100
      Re: [PATCH-tip v5 17/21] TP-futex: Group readers together in wait  queue Waiman Long <longman@redhat.com> - 2017-02-03 19:50 +0100
        Re: [PATCH-tip v5 17/21] TP-futex: Group readers together in wait queue valdis.kletnieks@vt.edu - 2017-02-03 20:30 +0100
  [PATCH-tip v5 05/21] futex: Add helpers to get & cmpxchg futex value without lock Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
  [PATCH-tip v5 04/21] futex: Rename futex_pi_state to futex_state Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
  [PATCH-tip v5 10/21] TP-futex: Enable robust handling Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
  [PATCH-tip v5 08/21] futex: Allow direct attachment of futex_state objects to hash bucket Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
  [PATCH-tip v5 03/21] futex: Consolidate duplicated timer setup code Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
  [PATCH-tip v5 19/21] perf bench: Extend mutex/rwlock futex suite to test TP futexes Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100
  [PATCH-tip v5 11/21] TP-futex: Implement lock handoff to prevent lock starvation Waiman Long <longman@redhat.com> - 2017-02-03 19:10 +0100

csiph-web