Re: [patch V2 3/7] futex: Add op for hash preallocation

From	Darren Hart <dvhart@infradead.org>
Newsgroups	linux.kernel
Subject	Re: [patch V2 3/7] futex: Add op for hash preallocation
Date	2016-05-19 21:40 +0200
Message-ID	<rABXB-41A-23@gated-at.bofh.it> (permalink)
References	<rvynE-79b-3@gated-at.bofh.it> <rvynE-79b-1@gated-at.bofh.it> <rvSw1-1EJ-3@gated-at.bofh.it> <rw65Y-6Am-3@gated-at.bofh.it> <rAvfr-8bz-1@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [patch V2 3/7] futex: Add op for hash preallocation Peter Zijlstra <peterz@infradead.org> - 2016-05-19 14:30 +0200
  Re: [patch V2 3/7] futex: Add op for hash preallocation Darren Hart <dvhart@infradead.org> - 2016-05-19 21:40 +0200

csiph-web