FS#36792 - [linux][linux-lts] increase CONFIG_NR_CPUS=64

Attached to Project: Arch Linux
Opened by Ivaylo Petrov (infestdead) - Wednesday, 04 September 2013, 15:22 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 14 October 2013, 07:31 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Currently I have access to several video encoding servers with latest Arch with 4xE7-4850 CPUs.
Each CPU has 10 cores and total 20 threads so I should see 80 cores, but I see 64 as that is the max currently set by CONFIG_NR_CPUS.
Currently I disable multithreading or install custom kernel.
I don't think increasing the CONFIG_NR_CPUS would harm anyone or cause anything unwanted.

Additional info:
* package version(s)
* config and/or log files etc.
/proc/config.gz

Steps to reproduce:
zgrep CONFIG_NR_CPUS /proc/config.gz
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Monday, 14 October 2013, 07:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  3.11.5
Comment by Tobias Powalowski (tpowa) - Wednesday, 04 September 2013, 15:39 GMT
Help text

You should set this to the number of CPUs in your system, but keep in mind that a kernel compiled for, e.g., 2 CPUs will boot but only use 2 CPUs on a >2 CPU system. Setting this to a value larger than 64 will cause the use of a CPU mask array, causing a small performance hit.

So it has an impact.
Comment by Thomas Bächler (brain0) - Wednesday, 04 September 2013, 16:16 GMT
As always, the help text doesn't state how "small" that performance hit really is. Anyway, as long as more than 64 cores are only the exception, I'd prefer to keep this value set to 64.
Comment by Ivaylo Petrov (infestdead) - Wednesday, 04 September 2013, 19:05 GMT
I didn't realize there was a performance hit if CONFIG_NR_CPUS is above 64 - if that is the case, I agree it's best to stay that way until more people start using significantly more cores. Until that happens I can always compile custom kernel. Cheers.
Comment by Karol Błażewicz (karol) - Wednesday, 04 September 2013, 22:31 GMT
 FS#21352 
> Comment by Thomas Bächler (brain0) - Tuesday, 26 October 2010, 08:51 GMT
> I suspect we will get requests for 96 or 128 cores in about one year, please open a new bug report then.

;P

Thomas, do you know how big the performance hit is? In  FS#21352  you mention only saving memory of the kernel image.
Comment by Thomas Bächler (brain0) - Thursday, 05 September 2013, 05:35 GMT
I only know what Tobias quoted above, sorry.

The memory impact is small and constant (at least that is what the help used to say, I can't see it in the part Tobias quoted).
Comment by Tobias Powalowski (tpowa) - Wednesday, 09 October 2013, 10:04 GMT
Sorry i quoted for wrong architecture, It's only about 8kb memory for each CPU, we speak about 512kb if increasing it.
Comment by Tobias Powalowski (tpowa) - Wednesday, 09 October 2013, 10:06 GMT
Checked in for both kernels, next builds will have new value.
Comment by Thomas Bächler (brain0) - Wednesday, 09 October 2013, 11:04 GMT
For reference: The help text Tobias quoted before was from the ia64 architecture.

This is the help text for x86:

"This allows you to specify the maximum number of CPUs which this kernel will support. The maximum supported value is 512 and the minimum value which makes sense is 2.

This is purely to save memory - each supported CPU adds approximately eight kilobytes to the kernel image."

Are we increasing to 128 now? Note that on 32 bit, the maximum is still 8, regardless of the help text saying 512.
Comment by Tobias Powalowski (tpowa) - Wednesday, 09 October 2013, 12:51 GMT
Ok, fixing i686 config for 8.
Comment by Thomas Bächler (brain0) - Wednesday, 09 October 2013, 12:59 GMT
It will fix itself during the build anyway. Relevant Kconfig snippet:

config NR_CPUS
int "Maximum number of CPUs" if SMP && !MAXSMP
range 2 8 if SMP && X86_32 && !X86_BIGSMP
range 2 512 if SMP && !MAXSMP
default "1" if !SMP
default "4096" if MAXSMP
default "32" if SMP && (X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000)
default "8" if SMP

There is an option called X86_BIGSMP "Support for big SMP systems with more than 8 CPUs" - I have no idea what other consequences that option has, but it would allow us to enable the value 128 for i686, too. I don't see the point in having more than 8 CPUs on i686.

Loading...