[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160506181843.GF48432@f23x64.localdomain>
Date: Fri, 6 May 2016 11:18:43 -0700
From: Darren Hart <dvhart@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Darren Hart <darren@...art.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Michael Kerrisk <mtk.manpages@...glemail.com>,
Davidlohr Bueso <dave@...olabs.net>, Chris Mason <clm@...com>,
Carlos O'Donell <carlos@...hat.com>,
Torvald Riegel <triegel@...hat.com>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [patch V2 3/7] futex: Add op for hash preallocation
On Thu, May 05, 2016 at 08:44:05PM -0000, Thomas Gleixner wrote:
> From: Sebastian Siewior <bigeasy@...utronix.de>
>
> The per process hash is allocated on the fly at the first futex operation of a
> process. The size of the hash is determined by a system wide default setting
> controlled by the sys admin, This is suboptimal for RT applications and
> applications with pathological futex abuse,
>
> - For RT applications its important to allocate the per process hash before the
> first futex operation to avoid the allocation on the first futex operation.
>
> - For pathological applications which use gazillions of futexes its useful to
> allocate a hash greater than the default hash size.
"it's" or preferably "it is"
>
> Add a futex op which allows to preallocate the hash with the requested
"allows for preallocating"
> size. The size is limited by the systemwide maximum hash size, which can be
system-wide
> set by the admin. The requested size is rounded up to the next order of 2.
>
> The function can be called several times, but ony the first call results in a
> hash allocation of the requested size as there is no non-intrusive way to
> reallocate/rehash in a multithreaded application.
>
> Note, that this call must be issued before the first futex operation in the
> process because that would automatically allocate the default sized hash.
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?
> The function returns the actual hash size or 0 if the global hash is used. The
> latter is the case on UP and in the rare case that the allocation failed and
> the global hash is used as a fallback.
>
> Signed-off-by: Sebastian Siewior <bigeasy@...utronix.de>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
...
--
Darren Hart
Intel Open Source Technology Center
Powered by blists - more mailing lists