public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Davidlohr Bueso <davidlohr@hp.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Jason Low <jason.low2@hp.com>,
	Darren Hart <dvhart@linux.intel.com>,
	Mike Galbraith <efault@gmx.de>, Jeff Mahoney <jeffm@suse.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Scott Norton <scott.norton@hp.com>, Tom Vaden <tom.vaden@hp.com>,
	Aswin Chandramouleeswaran <aswin@hp.com>,
	Waiman Long <Waiman.Long@hp.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC patch 0/5] futex: Allow lockless empty check of hashbucket plist in futex_wake()
Date: Sun, 1 Dec 2013 17:55:38 +0100	[thread overview]
Message-ID: <20131201165538.GA12864@gmail.com> (raw)
In-Reply-To: <20131201125604.GH16796@laptop.programming.kicks-ass.net>


* Peter Zijlstra <peterz@infradead.org> wrote:

> On Sun, Dec 01, 2013 at 01:10:22PM +0100, Ingo Molnar wrote:
>
> > But more importantly, since these are all NUMA systems, would it 
> > make sense to create per node hashes on NUMA? Each futex would be 
> > enqueued into the hash belonging to its own page's node.
> 
> Can't do that; we hash on vaddr, the actual page can move between 
> nodes while a futex is queued.

Hm, indeed. We used to hash on the physical address - the very first 
futex version from Rusty did:

+static inline struct list_head *hash_futex(struct page *page,
+                                          unsigned long offset)
+{
+       unsigned long h;
+
+       /* struct page is shared, so we can hash on its address */
+       h = (unsigned long)page + offset;
+       return &futex_queues[hash_long(h, FUTEX_HASHBITS)];
+}

But this was changed to uaddr keying in:

  69e9c9b518fc [PATCH] Unpinned futexes v2: indexing changes

(commit from the linux historic git tree.)

I think this design aspect could perhaps be revisited/corrected - in 
what situations can a page move from under a futex? Only via the 
memory migration system calls, or are there other channels as well? 
Swapping should not affect the address, as the pages are pinned, 
right?

Keeping the page invariant would bring significant performance 
advantages to hashing.

> This would mean that the waiting futex is queued on another node 
> than the waker is looking.

Yeah, that cannot work.

Thanks,

	Ingo

  reply	other threads:[~2013-12-01 16:55 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25 20:58 [RFC patch 0/5] futex: Allow lockless empty check of hashbucket plist in futex_wake() Thomas Gleixner
2013-11-25 20:58 ` [RFC patch 1/5] futex: Misc cleanups Thomas Gleixner
2013-11-25 20:58 ` [RFC patch 2/5] futex: Document ordering guarantees Thomas Gleixner
2013-11-25 20:58 ` [RFC patch 3/5] futex: Split out unlock from queue_me() Thomas Gleixner
2013-11-25 20:58 ` [RFC patch 4/5] futex: Enqueue waiter before user space check Thomas Gleixner
2013-11-26  0:20   ` Darren Hart
2013-11-25 20:58 ` [RFC patch 5/5] futex: Allow lockless empty check of hash bucket plist Thomas Gleixner
2013-11-26  8:12 ` [RFC patch 0/5] futex: Allow lockless empty check of hashbucket plist in futex_wake() Davidlohr Bueso
2013-11-26  8:52   ` Peter Zijlstra
2013-11-26 11:21     ` Ingo Molnar
2013-11-26 11:56       ` Peter Zijlstra
2013-11-26 12:34         ` Thomas Gleixner
2013-11-26 15:38           ` Davidlohr Bueso
2013-11-26 14:49         ` Davidlohr Bueso
2013-11-26 19:25     ` Davidlohr Bueso
2013-11-26 20:51       ` Davidlohr Bueso
2013-11-26 23:56         ` Thomas Gleixner
2013-11-28  7:44           ` Davidlohr Bueso
2013-11-28 11:58             ` Thomas Gleixner
2013-11-28 11:59             ` Peter Zijlstra
2013-11-28 14:23               ` Thomas Gleixner
2013-12-01  4:37               ` Davidlohr Bueso
2013-12-02 11:01                 ` Thomas Gleixner
2013-12-01 12:10               ` Ingo Molnar
2013-12-01 12:56                 ` Peter Zijlstra
2013-12-01 16:55                   ` Ingo Molnar [this message]
2013-12-01 18:58                     ` Linus Torvalds
2013-12-01 20:39                       ` Eric Dumazet
2013-12-01 21:46                         ` Linus Torvalds
2013-12-03 17:59                           ` Darren Hart
2013-12-02 12:35                       ` Ingo Molnar

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=20131201165538.GA12864@gmail.com \
    --to=mingo@kernel.org \
    --cc=Waiman.Long@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=aswin@hp.com \
    --cc=davidlohr@hp.com \
    --cc=dvhart@linux.intel.com \
    --cc=efault@gmx.de \
    --cc=jason.low2@hp.com \
    --cc=jeffm@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=scott.norton@hp.com \
    --cc=tglx@linutronix.de \
    --cc=tom.vaden@hp.com \
    --cc=torvalds@linux-foundation.org \
    /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