Re: [PATCH 2/9] Drop cpumask auto select patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 24, 2019 at 09:41:22AM -0500, Jeremy Linton wrote:
> Hi,
> 
> On 8/22/19 11:36 AM, Laura Abbott wrote:
> > 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.
> > 
> 
> Forgive me if you have already posted (didn't see it yet).
> 
> Its probably a good idea to bump the aarch64 config at the same time. Some
> aarch64 "desktop" machines is already at the 256 core limit currently in
> use.
> 

I've bumped aarch64 up to 4096, s390x up to 512, and powerpc up to 2048
in Rawhide and it'll be in the build after v5.4-rc6.

- Jeremy
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux