Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759382AbcDEP6R (ORCPT ); Tue, 5 Apr 2016 11:58:17 -0400 Received: from mail-qk0-f181.google.com ([209.85.220.181]:33513 "EHLO mail-qk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752143AbcDEP6Q (ORCPT ); Tue, 5 Apr 2016 11:58:16 -0400 Subject: Re: [RFC patch 4/7] futex: Add support for attached futexes To: Linus Torvalds , Ingo Molnar References: <20160402095108.894519835@linutronix.de> <20160402110035.753145539@linutronix.de> <20160403111628.GA16916@gmail.com> Cc: Thomas Gleixner , Andrew Morton , Peter Zijlstra , LKML , Sebastian Andrzej Siewior , Darren Hart , Peter Zijlstra , Michael Kerrisk , Davidlohr Bueso , Chris Mason , Torvald Riegel , Eric Dumazet From: "Carlos O'Donell" Organization: Red Hat Message-ID: <5703E092.2000601@redhat.com> Date: Tue, 5 Apr 2016 11:58:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1862 Lines: 49 On 04/03/2016 07:30 AM, Linus Torvalds wrote: > On Sun, Apr 3, 2016 at 6:16 AM, Ingo Molnar wrote: >> >> So an ABI distinction and offloading the decision to every single application that >> wants to use it and hardcode it into actual application source code via an ABI is >> pretty much the _WORST_ way to go about it IMHO... >> >> So how about this: don't add any ABI details, but make futexes auto-attached on >> NUMA systems (and obviously PREEMPT_RT systems)? > > I agree. > > Do *not* make this a visible new ABI. Agreed. We had similar requests in glibc to add APIs to tweak the parameters of the elision for locks backed by hardware transactional memory. The person submitting the patches always thinks this is a great API because it allows them to write tests to verify their own work (which means it still might be useful for internal testing or developing auto-tuning). Users have no clue what to do with the API and worse the state space of the parameters is immense. You can't possibly do any kind of sensible optimization without knowing a lot about the hardware. So no public API was ever added in glibc for pthread_mutex_lock elision parameters. Either the parameters work by default or you have to post patches to change the auto-tuning used internally in glibc. > So automatically using a local hashtable (for private mutexes - I > think people need to just accept that a shared mutex is more costly) > according to some heuristic is definitely the way to go. And yes, the > heuristic may be well be - at least to start - "this is a preempt-RT > system" (for people who clearly care about having predictable > latencies) or "this is actually a multi-node NUMA system, and I have > heaps of memory". Agreed. > Then, add a tunable (for root, not per-futex) to allow people to tweak it. Agreed. -- Cheers, Carlos.