[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250325225251.GO36322@noisy.programming.kicks-ass.net>
Date: Tue, 25 Mar 2025 23:52:51 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
André Almeida <andrealmeid@...lia.com>,
Darren Hart <dvhart@...radead.org>,
Davidlohr Bueso <dave@...olabs.net>, Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Valentin Schneider <vschneid@...hat.com>,
Waiman Long <longman@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v10 20/21] futex: Implement FUTEX2_NUMA
On Wed, Mar 26, 2025 at 01:22:19AM +0530, Shrikanth Hegde wrote:
> > + if (node == FUTEX_NO_NODE) {
> > + /*
> > + * In case of !FLAGS_NUMA, use some unused hash bits to pick a
> > + * node -- this ensures regular futexes are interleaved across
> > + * the nodes and avoids having to allocate multiple
> > + * hash-tables.
> > + *
> > + * NOTE: this isn't perfectly uniform, but it is fast and
> > + * handles sparse node masks.
> > + */
> > + node = (hash >> futex_hashshift) % nr_node_ids;
> > + if (!node_possible(node)) {
> > + node = find_next_bit_wrap(node_possible_map.bits,
> > + nr_node_ids, node);
> > + }
> > + }
> > +
> > + return &futex_queues[node][hash & futex_hashmask];
>
> IIUC, when one specifies the numa node it can't be private futex anymore?
The futex can be private just fine. It just won't end up in the process
private hash, since that is a single mm wide hash.
Powered by blists - more mailing lists