From: Peter Zijlstra <peterz@infradead.org>
To: "Christoph Lameter (Ampere)" <cl@gentwo.org>
Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org,
mingo@redhat.com, dvhart@infradead.org, dave@stgolabs.net,
andrealmeid@igalia.com, Andrew Morton <akpm@linux-foundation.org>,
urezki@gmail.com, hch@infradead.org, lstoakes@gmail.com,
Arnd Bergmann <arnd@arndb.de>,
linux-api@vger.kernel.org, linux-mm@kvack.org,
linux-arch@vger.kernel.org, malteskarupke@web.de,
llong@redhat.com
Subject: Re: [PATCH 2/6] futex: Implement FUTEX2_NUMA
Date: Mon, 28 Oct 2024 10:46:18 +0100 [thread overview]
Message-ID: <20241028094618.GL9767@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <dce4d83c-fb3f-3581-71e4-33dad3f91e07@gentwo.org>
On Fri, Oct 25, 2024 at 12:28:54PM -0700, Christoph Lameter (Ampere) wrote:
> On Fri, 25 Oct 2024, Peter Zijlstra wrote:
>
> > Extend the futex2 interface to be numa aware.
> >
> > When FUTEX2_NUMA is specified for a futex, the user value is extended
> > to two words (of the same size). The first is the user value we all
> > know, the second one will be the node to place this futex on.
> >
> > struct futex_numa_32 {
> > u32 val;
> > u32 node;
> > };
> >
> > When node is set to ~0, WAIT will set it to the current node_id such
> > that WAKE knows where to find it. If userspace corrupts the node value
> > between WAIT and WAKE, the futex will not be found and no wakeup will
> > happen.
> >
> > When FUTEX2_NUMA is not set, the node is simply an extention of the
> > hash, such that traditional futexes are still interleaved over the
> > nodes.
>
>
> Would it be possible to follow the NUMA memory policy set up for a task
> when making these decisions? We may not need a separate FUTEX2_NUMA
> option. There are supportive functions in mm/mempolicy.c that will yield
> a node for the futex logic to use.
Using get_task_policy() seems very dangerous to me. It is explicitly
possible for different tasks in a process to have different policies,
which means (private) futexes would fail to work correctly.
We need something that is process wide consistent -- like the vma
policies. Except at current, those are to expensive to readily access.
next prev parent reply other threads:[~2024-10-28 9:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 9:03 [PATCH 0/6] futex: The remaining futex2 bits Peter Zijlstra
2024-10-25 9:03 ` [PATCH 1/6] mm: Add vmalloc_huge_node() Peter Zijlstra
2024-10-25 9:58 ` Uladzislau Rezki
2024-10-25 16:00 ` Davidlohr Bueso
2024-10-25 19:54 ` Christoph Lameter (Ampere)
2024-10-25 9:03 ` [PATCH 2/6] futex: Implement FUTEX2_NUMA Peter Zijlstra
2024-10-25 18:30 ` Davidlohr Bueso
2024-10-28 9:38 ` Peter Zijlstra
2024-10-25 19:28 ` Christoph Lameter (Ampere)
2024-10-28 1:59 ` Davidlohr Bueso
2024-10-28 22:34 ` Christoph Lameter (Ampere)
2024-10-28 9:46 ` Peter Zijlstra [this message]
2024-10-28 22:37 ` Christoph Lameter (Ampere)
2024-10-25 21:23 ` André Almeida
2024-10-25 9:03 ` [PATCH 3/6] futex: Propagate flags into futex_get_value_locked() Peter Zijlstra
2024-10-25 9:03 ` [PATCH 4/6] futex: Enable FUTEX2_{8,16} Peter Zijlstra
2024-10-25 9:03 ` [PATCH 5/6] futex,selftests: Extend the futex selftests Peter Zijlstra
2024-10-25 9:03 ` [PATCH 6/6] futex,selftests: Extend the futex selftests for NUMA Peter Zijlstra
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=20241028094618.GL9767@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=andrealmeid@igalia.com \
--cc=arnd@arndb.de \
--cc=cl@gentwo.org \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=hch@infradead.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llong@redhat.com \
--cc=lstoakes@gmail.com \
--cc=malteskarupke@web.de \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.