CODEWITHSUNDEEP
linuxconfigurationcentosredhatmulticore
JustJeff
JustJeff

Reputation: 12980

How does RedHat determine the number of cores

First let me clarify what I am not asking -- I already know how to determine the number of cores that linux thinks it has, by querying items in /sys/devices/system/cpu such as ./possible and ./present, and by using lstopo, dmidecode, etc.

What I want to know is, how does the kernel arrive at the particular numbers one sees there in sys/devices/system/cpu/present ?

The motivation for this is that I have in my lab two identical processor boards, both with quad core i7-2715QE processors on them. One board, for simplicity's sake call this the 'good' board, reports as four cores (as expected) with hyperthreading (HT) on, for a total of 8 cpus. The other board reports only two cores, again with HT on, for a total of just 4 cpus.

Something upstream of sys/devices/system/cpu must be making the determination that two of the cores are not to be used. The 'good' board lists 0-7 in sys/.../possible and sys/.../present, whereas the 'bad' board shows 0-3, and yet they have the identical i7-2715QE on them.

I checked the BIOS/UEFI screens for any differences and didn't find anything there. There are no physical switches/jumpers on the board, that I can find. Could this have been something compiled into the kernel? Are the bootline options to Grub that I should look at? Both boards are running RedHat 6. The good board is at 6.3, the other one at 6.6, but these are similar enough to not innately make a difference in this regard. I.e., I don't think the version itself matters as much as the possibility that they're just build differently.

update

It's definitely something to do with the OS image or possibly the grub settings, b/c when booted from an external live image, the bad board shows the expected cpu0..cpu7 in sysfs. Something about what's in the on-board flash must be disabling two of the four cores.

Upvotes: 0

Views: 327

Answers (1)

JustJeff
JustJeff

Reputation: 12980

Turns out that the acpi option on the boot line is the culprit. For reasons not yet determined, specifying acpi=off was causing the kernel to misinterpret the cpu topology, and what should have been 4 cores with hyperthreading capability was taken to mean 4 cpus as 2 cores using hyperthreading.

Setting acpi=ht seemed to solve the problem.

Upvotes: 1

Related Questions