From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B3578462 for ; Fri, 27 Feb 2026 17:18:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772212710; cv=none; b=cM9lP4Jz+Q6ZYX99Jcls3PHCJMtZT9/LQrSSme7zEPNYD0aUTkFXrnsbMfVZk2Gi0mYkAVt+WkxcqmhAQpAN3g3kkMC7Qj65iMYKz5COuHcHgrRwM1JVyu4GfSBJsvMxp/jmrHnbgAcMM/sHOZTza9VAno1XUsWb/zK25Q9x3io= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772212710; c=relaxed/simple; bh=7zM1WP604KOGPLQtWU0aDhKTfD4n0jwSFhzAYhAgn+A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HILCjijDtQnqw5TcI1q80SV3nM9wOPCMDxjubm2He9zy/LEltnzl4GTOO6BdFmaO112tC047cFIRVfGYv5FrIIaznCmaF+MvBzlW3d6XP1QFEIgM5io0wB3BpUgvuUS1Xq4kV8FGDvZH3Gsb55e4hhMIDEKWA33OLI/rhPOIz6E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=ZRIr8hW3; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ZRIr8hW3" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=fgq2dnLqbNC9BZIArYJfJR6CbmLQRb7fkAoSMST40I8=; b=ZRIr8hW3+Wg37wxIWMcCRpxyvv t2GQa9eQEV5bamcNxa+jJURI+CTHtKYwJoqI4uKhLbHvDiGesL2C31kkTXYPwuFzIhGQqg6QNBbxw 95TyCUsJgWyb6BjFwYl2Rbi078onpw49nQ9nBoZVBWcoh6FCqwOeMpCFEBcY+M4Nr2Xf3wK1i4Ix5 73UH8S7eqs0GDG7KnAN5cJekRG4mrmpp1j+JuZFYZkCxfZ3Ho5VHvA0DHXruGzlsoaK5dxioCnY+b QvZFy86Vro1bNXqyU1F8RpBT8LuNuZIYN3CjhDHwu6CM38UyvKBVr9pi0eg7Lry6zzYDAk4pOrvKm eQD6QlTg==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vw1Ta-0000000DZfn-1IbX; Fri, 27 Feb 2026 17:18:19 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 228AF30066A; Fri, 27 Feb 2026 18:18:00 +0100 (CET) Date: Fri, 27 Feb 2026 18:18:00 +0100 From: Peter Zijlstra To: Sebastian Andrzej Siewior Cc: K Prateek Nayak , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, Darren Hart , Davidlohr Bueso , =?iso-8859-1?Q?Andr=E9?= Almeida Subject: Re: [RFC PATCH] futex: Dynamically allocate futex_queues depending on nr_node_ids Message-ID: <20260227171800.GK606826@noisy.programming.kicks-ass.net> References: <20260128101358.20954-1-kprateek.nayak@amd.com> <20260227144203.GJ1282955@noisy.programming.kicks-ass.net> <20260227161841.GH606826@noisy.programming.kicks-ass.net> <20260227171230.b4w4sE25@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260227171230.b4w4sE25@linutronix.de> On Fri, Feb 27, 2026 at 06:12:30PM +0100, Sebastian Andrzej Siewior wrote: > On 2026-02-27 17:18:41 [+0100], Peter Zijlstra wrote: > > Ooh, I just remebered, I've always wanted to apply Linus' runtime-const > > stuff to the futex thing. > > I wasn't aware we have this, I did want to do/ have something like this. > > Need to look at this in detail but… > > > --- a/kernel/futex/core.c > > +++ b/kernel/futex/core.c > > @@ -439,14 +442,14 @@ __futex_hash(union futex_key *key, struct futex_private_hash *fph) > > * NOTE: this isn't perfectly uniform, but it is fast and > > * handles sparse node masks. > > */ > > - node = (hash >> futex_hashshift) % nr_node_ids; > > + node = runtime_const_shift_right_32(hash, __futex_shift) % nr_node_ids; > > getting rid of that div here would be the next step. If we could round > it up to the next pow2 then we could avoid it. But I remember it did not > show up in bench as much as I was thinking it would. Right, modern x86 seems really rather good at division (unlike a few years ago). But yes, it would be nice to do better there.