From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754655AbcESTgw (ORCPT ); Thu, 19 May 2016 15:36:52 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:46334 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754563AbcESTgu (ORCPT ); Thu, 19 May 2016 15:36:50 -0400 Date: Thu, 19 May 2016 12:36:42 -0700 From: Darren Hart To: Peter Zijlstra Cc: Thomas Gleixner , LKML , Sebastian Andrzej Siewior , Linus Torvalds , Darren Hart , Ingo Molnar , Michael Kerrisk , Davidlohr Bueso , Chris Mason , "Carlos O'Donell" , Torvald Riegel , Eric Dumazet Subject: Re: [patch V2 3/7] futex: Add op for hash preallocation Message-ID: <20160519193642.GA1872@f23x64.localdomain> References: <20160505204230.932454245@linutronix.de> <20160505204354.051976225@linutronix.de> <20160506181843.GF48432@f23x64.localdomain> <20160519122849.GD3192@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160519122849.GD3192@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 19, 2016 at 02:28:49PM +0200, Peter Zijlstra wrote: > On Sat, May 07, 2016 at 10:47:38AM +0200, Thomas Gleixner wrote: > > On Fri, 6 May 2016, Darren Hart wrote: > > > > So this seems like it could be tricky for the user as system libraries, like > > > glibc, make use of futexes. Can we guarantee that "sys_futex" is not called by > > > the time main() is called? > > > > To the extent of my testing I never observed that the hash was automatically > > created when I called futex(PREALLOC) right away in main. But yes, that might > > need some thought. > > I suspect that even if glibc uses futexes before main(), they will not > be contended, because, last time I checked, the C runtime environment is > very much single threaded unless explicitly made not so by the program. > > In any case (re)hashing if the hash is empty is 'easy', if there's already state, > not so much. It certainly would be nice to be able to resize the hash if it's empty. -- Darren Hart Intel Open Source Technology Center