Re: [RFC PATCH] futex: Dynamically allocate futex_queues depending on nr_node_ids

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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