From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751865AbdBCSmt convert rfc822-to-8bit (ORCPT ); Fri, 3 Feb 2017 13:42:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41826 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751728AbdBCSmr (ORCPT ); Fri, 3 Feb 2017 13:42:47 -0500 Subject: Re: [PATCH-tip v5 17/21] TP-futex: Group readers together in wait queue To: valdis.kletnieks@vt.edu References: <1486145034-22210-1-git-send-email-longman@redhat.com> <1486145034-22210-18-git-send-email-longman@redhat.com> <13281.1486146235@turing-police.cc.vt.edu> Cc: Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Jonathan Corbet , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Arnaldo Carvalho de Melo , Davidlohr Bueso , Mike Galbraith , Scott J Norton From: Waiman Long Organization: Red Hat Message-ID: <275d5112-eaa8-1158-b26d-4e18c8bf79e1@redhat.com> Date: Fri, 3 Feb 2017 13:42:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <13281.1486146235@turing-police.cc.vt.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 03 Feb 2017 18:42:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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