From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 5108238F249 for ; Wed, 25 Feb 2026 09:22:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772011338; cv=none; b=Sd2axmUZaj3M2W4PDsN4287+EuD/FLewSX8ZYvUwE/c4Tg1k2J4N+vWyiwAvqOgPrJ8quGhfx7ZC/5cu6vYh7m2h2GlR6twLxoGO8YVq+G9Hui1ayfl4GO5hlUE6wvJ0uuS4hrZ/Zl8/Lky+G0lgpByfZSzOOd0fY6zFEHp5mUQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772011338; c=relaxed/simple; bh=RqNvk6/u42J6+KOwxxLWXIidhH4Tsvn5N36OHT3hApY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PvWH7EAEV3hIqu3msnzNBJ4WTVMYsIxPVKhk2sEAdyu17Y8I/xqKqoP0/p0wWghVPEfgzfIHJLjbwwm5+7qf7ILu5D0X4LHDfbe8MDa3fob+XY4aGzJjTPX82sceHSRL0xPoIwvxoGrX/DCMD75XLNP32gx8NrpiJwcWoZ6h6M8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=WiJSFypC; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=zLBC/FKb; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="WiJSFypC"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="zLBC/FKb" Date: Wed, 25 Feb 2026 10:22:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1772011335; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/J51P6Ivk4NEdXN14+1eBtU6vziSrmNha2Z2q3UsrTI=; b=WiJSFypCFLSdNrQu4CNYlu5qGxT7qChSf6O0R8ZVM5vK8NF9CrfdQkkejPWeMyPXRnGCyu 9neEqeVTlO8sm3MABy3p70GvXV+VkQoBfH1OkSYkvWm+I70OcTdXehy4s8JNnJc1+SrMZf 4y7+9d4mi8bWsbYbEElyJPi+kD4nW0svqGaJYGzM3J/IOzPb9aEeHKwhFDDZXmwiN6fPEO 2IlHkPLtEW8/b4bH/n5CRvV1tmQt+Ytiue/+FW4k7/hA0pD1zdw6SeIuAg7pwyjqEAYRuX vZHNeD7DuXF+kNvXMIxA7YN+h0f/BkKlXVidNrVrhHLOvEwuVtOmPnzKb/IjJg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1772011335; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/J51P6Ivk4NEdXN14+1eBtU6vziSrmNha2Z2q3UsrTI=; b=zLBC/FKb23wIKRtUKqaseiL24tQhjgFgfTPMFxqRCRuFfZ4SujJ1ZMp0o/txThWnvhm/ME GjkFfamH4Hz4uWDw== From: Sebastian Andrzej Siewior To: K Prateek Nayak Cc: Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, Peter Zijlstra , Darren Hart , Davidlohr Bueso , =?utf-8?B?QW5kcsOp?= Almeida Subject: Re: [RFC PATCH] futex: Dynamically allocate futex_queues depending on nr_node_ids Message-ID: <20260225092213.oRHJyLG5@linutronix.de> References: <20260128101358.20954-1-kprateek.nayak@amd.com> <20260224111342.-9hafXl5@linutronix.de> <20260225073939.HLbwiSs5@linutronix.de> <99a81417-5dbf-4c29-8dac-a9ed17ee24d6@amd.com> 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 In-Reply-To: <99a81417-5dbf-4c29-8dac-a9ed17ee24d6@amd.com> On 2026-02-25 14:21:33 [+0530], K Prateek Nayak wrote: Hi Prateek, > I would have thought a quarter of that would be plenty but looking at > the footnote in [1] that says "16 socket GNR system" and the fact that > GNR can feature up to 256 threads per socket - that could theoretically > put such systems at that NR_CPUS_DEFAULT limit - I don't know if it is > practically possible. > > [1] https://lore.kernel.org/lkml/aYPjOgiO_XsFWnWu@hpe.com/ > > Still, I doubt such setup would practically cross more than 64 nodes. I am still trying to figure out if this is practical or some drunk guys saying "you know what would be fun?" > Why was this selected as the default for MAXSMP? It came from [2] but > I'm not really able to understand why other than this line in Mike's > response: > > "MAXSMP" represents what's really usable > > so we just set it to the max of range to test for scalability? Seems > little impractical for real-world cases but on the flip side if we > don't sit it, some bits might not get enough testing? Sounds like it. What would be sane default upper limit then? Something like 1024 CPUs? 2048? Or even more than that? I would try to use this and convince Debian to drop MAXSMP and then lower NODES_SHIFT to default 6. I would need a default for NR_CPUS_DEFAULT without having people complaining about missing CPUs. Maybe we could get a sane default setting in kernel without testing limits. Also probably will compile two kernels to see how much memory this safes in total since there should be other data structures depending on max CPUs/ NODEs. Sebastian