32

I am a bit confused about the number of CPUs my server has.

It is running on Intel(R) Xeon(R) Gold 6242R CPU @ 3.10GHz which according to official Intel docs contains 20 physical cores.

The problem here is the output of lscpu command (some rows filtered):

CPU(s):                          80
On-line CPU(s) list:             0-79
Thread(s) per core:              2
Core(s) per socket:              20
Socket(s):                       2
NUMA node(s):                    2
Model name:                      Intel(R) Xeon(R) Gold 6242R CPU @ 3.10GHz
NUMA node0 CPU(s):               0-19,40-59
NUMA node1 CPU(s):               20-39,60-79

From what I understand actual physical cores = CPU(s) / thread(s) per core but then I get 40 which is double of what I expect.

Can someone please explain me what is going on here and what exactly CPU(s), thread(s) per core, core(s) per socket, socet(s) mean?

4
  • Device manager is the easiest place to see how many physical cpu's you have.
    – Moab
    Dec 6 '21 at 13:04
  • 1
  • 10
    Nitpick: ‘physical CPUs’ is ambiguous. Depending on context it could mean CPU packages (you have two), CPU dies (you probably have two, AMD Ryzen Threadripper chips are an example of chips with more than one die per package), ‘physical’ CPU cores (you have 40), or even total schedulable CPUs (you have 80, this meaning is pretty specific to working with virtualization though). Dec 6 '21 at 18:34
  • 6
    @AustinHemmelgarn If they had a correct understanding of the different possible meanings of physical CPU they wouldn't be asking this question..
    – Nobody
    Dec 6 '21 at 21:49
62
  • Sockets represents how many physical CPUs are in the system.

  • Cores per socket is how many full CPU cores (including loading/decoding logic) there are per physical CPU.

  • Threads per core is how many threads can be scheduled on a single core (HyperThreading). Simply said, the hardware in the CPU that is used before the actual execution of code is doubled, allowing the CPU to have multiple different tasks ready for execution. It allows the CPU to fetch/decode instructions before they hit the execution core of the CPU. It prevents or reduces pipeline stall.

  • CPU means "schedulable entities", this is how many run queues the operating system will have, so that would be sockets x cores per socket x threads per core

In your case, you have 2 physical CPUs, which each have 20 cores, which each can run 2 threads (hyperthreading). So 2x20x2 = 80, which is the number of CPUs displayed.

3
  • "Sockets represents how many physical CPUs are in the system." – Doesn't it represent the number of sockets, not the number of CPUs? You could have more than one CPU per socket. In older systems, where a single CPU consisted of multiple chips, you could even have more than one socket per CPU. Dec 6 '21 at 23:17
  • 1
    I don't have a reference for this, but from experience I know that if a socket on the motherboard is unoccupied, it does not show up as a "socket" in lscpu. As for having more than one CPU per socket, my experience is mostly with Intel and SPARC systems, I've never seen more than a single CPU in a single socket, so I wouldn't know how Linux would report something like that. @JörgWMittag Just out of curiousity, which CPUs did have this "architecture"?
    – mtak
    Dec 6 '21 at 23:23
  • 7
    @mtak Some historical ‘NUMA-on-a-chip’ systems reported like this. Physically, they were much like the biggest modern AMD Ryzen and EPYC chips, with multiple dies per package, except that the system identified each die as a separate CPU for scheduling reasons (because each die was in it’s own NUMA domain). The norm, IIRC, for such systems was that ‘sockets’ would be logical packages (IOW, total number of physical dies in the system, not physical packages) because this mapped one socket per NUMA domain, which worked correctly without needing modifications to the scheduler. Dec 6 '21 at 23:41
16

The confusion comes from a very simple detail that might be unclear from the info lscpu command is showing you.

The thing is: your server actually has 2 Intel(R) Xeon(R) Gold 6242R CPUs, which is mentioned in the Socket(s) row.

As the Intel documentation states, each one of those CPUs contains 20 physical cores (the Core(s) per socket line) which gives a total of 40 physical cores.

Each one of those cores is able to run 2 threads "simultaneously" (the Thread(s) per core line).

So: 2 Intel Xeon, 20 physical cores each one, 2 threads each core, gives a total of 80 "units that can execute a process" or "CPUs"

8

The idea of a CPU is a bit of an abstraction now, and this started with hyperthreading (late 90's) and then the Intel Core (early 00's) series. Before then you definitely had multiple-CPU systems but they were all multiple-physical-CPU.

But with hyperthreading and multiple-core single CPUs, the physical # of CPUs is different than the logical # of CPUs the running code on the CPUs sees.

Socket(s):                       2

You have 2 physical CPUs as in "thing with heatsink plugged into your motherboard"

Core(s) per socket:              20

Each physical CPU has 20 cores, which look and mostly work like independent CPUs to Linux. Cores share at least the same L3 cache, probably L2 cache, and probably have their own L1 cache - so not quite as peformant as individual sockets with their own L3/L2/L1 but nearly there.

Since that's each socket, you have 2 * 20 = 40.

Thread(s) per core:              2

Each core has 2 SMT threads, which are implemented by your CPU's microarchitecture to basically look mostly like independent CPUs to Linux

They're not going to be anywhere as fast as real independent cores.

Threads on the microarchitecture try to grab currently unused pipeline stages from cores but might have to end up waiting if busy--and CPUs already try to keep themselves very busy, so again 2 threads on 2 cores is nowhere near equivalent to 4 cores, but it is something that can make code run a bit faster.

Note that Spectre and similar vulnerabilities are much more possible across threads than cores or sockets because core resources are shared.

Anyway, since that's per core, and also per socket, that's 2 * 20 * 2, which gives you:

CPU(s):                          80
1
  • 3
    Minor nitpick: Any x86 server CPU less than 10-15 years old (Xeons since Nehalem, AMDs since K10) has a dedicated L2 cache for each core. L3 is the one shared across cores.
    – TooTea
    Dec 8 '21 at 8:01
5

Dual CPU… processors x2, 20 cores per socket…x2 = 40 cores = 80 with HT.
This is probably very easy to verify by simply taking the lid/side off.

1
  • 29
    It is not as easy to take the lid/side off when the server is on a different continent
    – eddyP23
    Dec 7 '21 at 7:58
4

Your server is using 2 "Processor-Chips" (on the 2 Sockets), which have 20 physical cores each.

And each core can process 2 threads.

That's why it displays 2 (Processor-Chips) * 20 (Cores per part) * 2 (Threads each core can process) = 80 CPUs

In this case CPU stands for "schedulable entity" aka. the ammount of threads, which can be run by the machine.

1
  1. A motherboard can have multiple sockets
  2. Each socket can have a single physical processor
  3. Each processor can have one or more cores
  4. Each core can execute one or two threads concurrently

You have 2 sockets filled with one processor each, 20 cores per processor, and 2 threads per core.

2 x 20 x 2 = 80 CPUs


I think that 80 CPUs is a misnomer and simply a by-product of history because in the past only single-core/thread processors existed so processor, CPU, core, and thread was all used interchangeably.

2
  • 2
    Yeah, it doesn't help that "thread" is really a software-based term (meaning a way to have a single process get more than 1 slot on the operating system's CPU scheduler). I like the terminology RISC-V uses - "hardware threads" or "harts".
    – LawrenceC
    Dec 7 '21 at 20:46
  • @LawrenceC Agreed; albeit it's technically software running directly on the CPU. Opening my Task Manager reveals 3222 threads and I can guarantee you that my laptop does not have 1,611 cores!
    – MonkeyZeus
    Dec 7 '21 at 20:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.