mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Darren Hart <darren@dvhart.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Michael Kerrisk <mtk.manpages@googlemail.com>,
	Davidlohr Bueso <dave@stgolabs.net>, Chris Mason <clm@fb.com>,
	"Carlos O'Donell" <carlos@redhat.com>,
	Torvald Riegel <triegel@redhat.com>,
	Eric Dumazet <edumazet@google.com>
Subject: Re: [patch V2 3/7] futex: Add op for hash preallocation
Date: Fri, 6 May 2016 11:18:43 -0700	[thread overview]
Message-ID: <20160506181843.GF48432@f23x64.localdomain> (raw)
In-Reply-To: <20160505204354.051976225@linutronix.de>

On Thu, May 05, 2016 at 08:44:05PM -0000, Thomas Gleixner wrote:
> From: Sebastian Siewior <bigeasy@linutronix.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@linutronix.de>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

...

-- 
Darren Hart
Intel Open Source Technology Center

  reply	other threads:[~2016-05-06 18:18 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-05 20:44 [patch V2 0/7] futex: Add support for process private hashing Thomas Gleixner
2016-05-05 20:44 ` [patch V2 1/7] futex: Add some more function commentry Thomas Gleixner
2016-05-06 17:37   ` Darren Hart
2016-05-05 20:44 ` [patch V2 2/7] futex: Hash private futexes per process Thomas Gleixner
2016-05-06 18:09   ` Darren Hart
2016-05-06 21:56     ` Darren Hart
2016-05-07  8:45       ` Thomas Gleixner
2016-05-11 21:08         ` Darren Hart
2016-05-07  8:44     ` Thomas Gleixner
2016-05-11 21:07       ` Darren Hart
2016-05-27 16:36       ` Sebastian Andrzej Siewior
2016-05-19 12:21   ` Peter Zijlstra
2016-05-27 16:52     ` Sebastian Andrzej Siewior
2016-05-30  8:43       ` Peter Zijlstra
2016-05-19 12:24   ` Peter Zijlstra
2016-05-27 17:10     ` Sebastian Andrzej Siewior
2016-05-30  8:58       ` Peter Zijlstra
2016-05-30 11:08         ` Sebastian Andrzej Siewior
2016-05-30 12:06           ` Peter Zijlstra
2016-05-30 13:37             ` Sebastian Andrzej Siewior
2016-05-30 13:49               ` Peter Zijlstra
2016-05-30 13:59                 ` Sebastian Andrzej Siewior
2016-05-30 14:02                   ` Peter Zijlstra
2016-05-05 20:44 ` [patch V2 3/7] futex: Add op for hash preallocation Thomas Gleixner
2016-05-06 18:18   ` Darren Hart [this message]
2016-05-07  8:47     ` Thomas Gleixner
2016-05-07 11:40       ` Thomas Gleixner
2016-05-19 12:28       ` Peter Zijlstra
2016-05-19 19:36         ` Darren Hart
2016-05-19 12:24   ` Peter Zijlstra
2016-05-19 19:38     ` Darren Hart
2016-05-20  4:50       ` Peter Zijlstra
2016-05-19 12:25   ` Peter Zijlstra
2016-05-27 17:27     ` Sebastian Andrzej Siewior
2016-05-30  8:59       ` Peter Zijlstra
2016-05-05 20:44 ` [patch V2 4/7] futex: Add sysctl knobs for process private hash Thomas Gleixner
2016-05-06 18:22   ` Darren Hart
2016-05-27 17:33     ` Sebastian Andrzej Siewior
2016-05-05 20:44 ` [patch V2 5/7] perf/bench/futex-hash: Support NUMA Thomas Gleixner
2016-05-05 20:44 ` [patch V2 6/7] perf/bench/futex-hash: Support preallocate hash table Thomas Gleixner
2016-05-05 20:44 ` [patch V2 7/7] futex.2: Document hash preallocation opcode Thomas Gleixner
  -- strict thread matches above, loose matches on Subject: below --
2016-05-05 19:03 [patch V2 0/7] Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Linus Torvalds <torvalds@linux-foundation.org>, Darren Hart <darren@dvhart.com>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Michael Kerrisk <mtk.manpages@googlemail.com>, Davidlohr Bueso <dave@stgolabs.net>, Chris Mason <clm@fb.com>, Carlos O'Donell <carlos@redhat.com>, Torvald Riegel <triegel@redhat.com>, Eric Dumazet <edumazet@google.com> Thomas Gleixner
2016-05-05 19:03 ` [patch V2 3/7] futex: Add op for hash preallocation Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160506181843.GF48432@f23x64.localdomain \
    --to=dvhart@infradead.org \
    --cc=bigeasy@linutronix.de \
    --cc=carlos@redhat.com \
    --cc=clm@fb.com \
    --cc=darren@dvhart.com \
    --cc=dave@stgolabs.net \
    --cc=edumazet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mtk.manpages@googlemail.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=triegel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®