Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757345AbcDEHok (ORCPT ); Tue, 5 Apr 2016 03:44:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58960 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753938AbcDEHoj (ORCPT ); Tue, 5 Apr 2016 03:44:39 -0400 Message-ID: <1459842272.1991.34.camel@localhost.localdomain> Subject: Re: [RFC patch 4/7] futex: Add support for attached futexes From: Torvald Riegel To: Linus Torvalds Cc: Ingo Molnar , Thomas Gleixner , Andrew Morton , Peter Zijlstra , LKML , Sebastian Andrzej Siewior , Darren Hart , Peter Zijlstra , Michael Kerrisk , Davidlohr Bueso , Chris Mason , "Carlos O'Donell" , Eric Dumazet Date: Tue, 05 Apr 2016 09:44:32 +0200 In-Reply-To: References: <20160402095108.894519835@linutronix.de> <20160402110035.753145539@linutronix.de> <20160403111628.GA16916@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2152 Lines: 42 On Sun, 2016-04-03 at 06:30 -0500, 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. >From a glibc perspective, I agree that this shouldn't require an extension of the ABI unless it's really the only possible way to solve this. For "special" mutex kinds such as PI mutexes, the change in the interface might be justifiable -- but for ordinary mutexes, there's no good place to add the attach/detach calls in each thread: An implementation of, say, C11 mutexes cannot easily estimate whether it should use attached futexes, and it would have to track whether a particular mutex has been attached to by the current thread; this might just move the overhead of tracking and caching associations from the kernel to userspace. > 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). There are cases where userspace might know that it should use a "special" futex. Consider an MCS-lock implementation in glibc by which all pthreads, C, and C++ mutexes are backed: the lock nodes that threads would be spinning on would be per-thread and exist for the whole lifetime of the thread; attach and detach would be simple to do, and there would be a limited number of these in the system. A Java VM's park/unpark implementation might be another candidate. However, these use cases are pretty specific (eg, there's only a single waiter), so any kernel support for these might be more special too.