Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753494AbcDCLap (ORCPT ); Sun, 3 Apr 2016 07:30:45 -0400 Received: from mail-ig0-f193.google.com ([209.85.213.193]:33563 "EHLO mail-ig0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752618AbcDCLao (ORCPT ); Sun, 3 Apr 2016 07:30:44 -0400 MIME-Version: 1.0 In-Reply-To: <20160403111628.GA16916@gmail.com> References: <20160402095108.894519835@linutronix.de> <20160402110035.753145539@linutronix.de> <20160403111628.GA16916@gmail.com> Date: Sun, 3 Apr 2016 06:30:38 -0500 X-Google-Sender-Auth: DPWb8D1jrucwCgxrZ1ClmksPdVU Message-ID: Subject: Re: [RFC patch 4/7] futex: Add support for attached futexes From: Linus Torvalds To: Ingo Molnar Cc: Thomas Gleixner , Andrew Morton , Peter Zijlstra , LKML , Sebastian Andrzej Siewior , Darren Hart , Peter Zijlstra , Michael Kerrisk , Davidlohr Bueso , Chris Mason , "Carlos O'Donell" , Torvald Riegel , Eric Dumazet Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1738 Lines: 39 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. You will find that people will make exactly the wrong choices - either not using it (because the futex is deep in a standard library!) when they want to, or using it when they shouldn't (because the futex is deep in a standard library, and the library writer knows *his* code is so important that it should get a special faster futex). So I absolutely detest this approach. It's the wrong way to go about things. User space does *not* know whether they want to use this or not, and they *will* be wrong. 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". Then, add a tunable (for root, not per-futex) to allow people to tweak it. Because the *last* thing you want is programmerrs saying "I'm so important that I want the special futex". Because every single programmer thinks they are special and that _their_ code is special. I know - because I'm special. Linus