News HPE's unnamed 1,152-core system pushes Turbostat to support 8,192 cores in Linux 6.15

[Admin]

Linux 6.15 resolves Turbostat's incompatibility with high core count systems, now supporting up to 8,192 cores.

HPE's unnamed 1,152-core system pushes Turbostat to support 8,192 cores in Linux 6.15 : Read more

 

[A Stoner]

8192 is 13 bits, an odd place to stop, but I guess it does not make sense to go to 16 bits and 65,536 support at this point in time.

 

[Jame5]

2x 288 core CPUs is 576 cores.

w/ HT (though I'm pretty sure the 288 core CPUs don't have it), that would be exactly 1152.

Is there a 4-socket solution that can take the 288 core sierra forest CPUs?

 

[qxp]

2x 288 core CPUs is 576 cores.

w/ HT (though I'm pretty sure the 288 core CPUs don't have it), that would be exactly 1152.

Is there a 4-socket solution that can take the 288 core sierra forest CPUs?

Turbostat reports both per core and per hyperthread info. For example, the core temperature is reported once per core, but IRQ count is per execution thread. From the description in the article, I would assume they did need more cores.

 

[bit_user]

8192 is 13 bits, an odd place to stop, but I guess it does not make sense to go to 16 bits and 65,536 support at this point in time.

The issue is not the number of bits, but rather the size of the static data structures needed to support all of those cores. Any tables used to track stuff on a per-core basis need to be enlarged to support the max number of cores the kernel is compiled with.

 

[bit_user]

2x 288 core CPUs is 576 cores.

w/ HT (though I'm pretty sure the 288 core CPUs don't have it), that would be exactly 1152.

Is there a 4-socket solution that can take the 288 core sierra forest CPUs?

I think this is probably for an 8-socket solution, which the top tier Intel CPUs traditionally support. My guess is that the number was enlarged to support hyperthreads, in which case it would require 8x 72-core CPUs to reach. Given Intel's Xeon 6 models that support hyperthreading have up to 128 physical cores, it's easy to believe.

AMD's EPYCs haven't supported more than 2S scalability and I don't see that changing. Higher socket-count is a niche market that's probably shrinking in at least relative size, as server CPU core counts continue to balloon. I think it's too early for HPE to be testing the next gen AMD EPYCs, but it's not so hard to fathom a 288-core Zen 6C EPYC.

 

[A Stoner]

The issue is not the number of bits, but rather the size of the static data structures needed to support all of those cores. Any tables used to track stuff on a per-core basis need to be enlarged to support the max number of cores the kernel is compiled with.

I started wondering if there was static data that needed to be held and reserved after I made the comment. So, you are likely right.