On 8/22/19 8:58 AM, Prarit Bhargava wrote:
On 8/19/19 9:15 AM, Laura Abbott wrote:
> On 8/16/19 2:57 PM, Paul Bolle wrote:
>> Florian Weimer schreef op vr 16-08-2019 om 14:04 [+0200]:
>>> RHEL has a larger NR_CPU value, though. For example, it's 8192 on
>>> x86-64, while Fedora 31 has 1024.
>> On the Fedora x86-64 debug builds it's 8192 again. Why's that?
>> Paul Bolle
> That's the option for max cpus. We don't want to turn it on in all
> Fedora builds since it would use up more resources we probably don't
> actually need. Turning on for debugging in Fedora is okay though.
> RHEL is focused on larger footprints and makes the trade off to
> have it enabled all the time.
I think I measured the impact of 8192 vs 512 (or 256?) a long time ago and we
are talking about _k_ of memory. We should stick with what upstream has at
8192. It's easier to debug when we have the same value as the default IMO.
Having said that, it has been a long time since I had to debug a NR_CPUS/nr_cpus
issue in the kernel. We're just not seeing bugs around the value anymore.
I was going to ask about the actual impact of a larger number of CPUs. If it's
actually only k of memory it's probably better to just set MAXCPUS all the time.
Even the lowest end machines probably see more change when frameworks change.
And yes, I also think that we've come a long way so NR_CPUS is less of an important
option to optimize these days. I think I'll just submit another patch to just do
the max cpus.