Linux CPU Cores vs Threads Explained | Physical Cores, Logical CPUs & SMT

Introduction

A Linux server may show eight CPUs in lscpu, but that does not necessarily mean it has eight physical CPU cores.

Modern CPUs combine multiple physical cores with SMT (Simultaneous Multithreading), which can expose one physical core to Linux as multiple logical CPUs. Understanding the difference between sockets, physical cores, hardware threads, and logical CPUs is essential when interpreting CPU topology and analyzing Linux CPU performance.

More cores or logical CPUs also do not guarantee performance gains in direct proportion to their number. Application parallelism, CPU caches, memory bandwidth, lock contention, CPU migration, and shared execution resources can all limit scaling.

This article explains how Linux sees multicore CPU topology, how SMT works, how to inspect the topology from Linux, and why multicore performance does not simply scale with core count.

What Is a Multicore CPU?

A multicore CPU contains several CPU cores in one CPU package. Each core has execution mechanisms for fetching, decoding, and processing instructions. By processing separate instruction streams, multiple cores can execute several tasks in parallel.

Differences Between CPU, Core, Hardware Thread, and Logical CPU

The term CPU has different meanings depending on the context. It may refer to a physical CPU package or to a logical CPU recognized by Linux. When the physical hardware needs to be distinguished explicitly, terms such as physical CPU or socket are useful.

A core is an independent processing core within a physical CPU package that can execute its own instruction stream. A four-core CPU therefore contains four physical cores.

The word thread can also refer to different concepts. A software thread is an execution flow created by a process, while a hardware thread is a hardware execution context that can be exposed to the OS as a logical CPU. With SMT, one physical core can provide multiple hardware threads and therefore appear to Linux as multiple logical CPUs.

Single-Core vs. Multicore CPUs

If a single-core CPU has three runnable tasks, Task A, Task B, and Task C, the core executes them by switching between tasks in turn.

On a four-core CPU running four tasks, one task can be assigned to each core. If those tasks can proceed without waiting for one another to finish, they can run in parallel during the same period.

Having four tasks does not necessarily mean all four cores will be used. Actual placement depends on task states, CPU affinity, scheduling policies, the load from other tasks, and other factors. Tasks that are waiting do not execute instructions on a CPU, so task count and CPU utilization do not have a simple one-to-one relationship.

Physical CPUs, CPU Cores, and Logical CPUs

When inspecting CPU configuration in Linux, the distinction between sockets, cores, and logical CPUs is particularly important. Understanding these three concepts helps you interpret the CPU topology that Linux exposes correctly.

Socket

A socket is a physical CPU mounting point on the motherboard. In general, the socket count corresponds to the number of installed physical CPU packages. A single-socket server normally contains one physical CPU, while a dual-socket server normally contains two.

Core

A core is an instruction-execution unit inside a physical CPU. One socket can contain several cores. A common configuration gives each core its own L1 and L2 caches while sharing resources such as L3 cache among multiple cores. The exact configuration depends on the CPU.

Logical CPU

A logical CPU is a CPU execution unit that the OS recognizes as a target for scheduling tasks. With SMT disabled, one core normally corresponds to one logical CPU. With two-thread-per-core SMT enabled, one core is normally recognized as two logical CPUs.

Linux assigns a CPU number to each logical CPU. If CPU0 through CPU7 are present and online, Linux sees eight online logical CPUs. However, those eight CPU numbers do not necessarily represent eight independent physical cores.

Checking with lscpu

In Linux, lscpu shows the number of sockets, cores per socket, threads per core, and logical CPUs.

For example, suppose the relevant fields show the following.

Socket(s):                1
Core(s) per socket:       4
Thread(s) per core:       2
CPU(s):                   8

This system has one physical CPU containing four physical cores. Each core supports two hardware threads, so Linux recognizes eight logical CPUs in total.

1 Socket
   ↓
4 Cores
   ↓
2 Threads / Core
   ↓
8 Logical CPUs

The basic relationship is: socket count × cores per socket × threads per core = logical CPU count. In this example, 1 × 4 × 2 = 8.

In a virtual machine, the topology displayed by lscpu does not necessarily match the physical host’s actual configuration. Virtual CPU topology is information presented to the guest OS by the hypervisor. Its correspondence to physical host cores and threads depends on the environment.

Checking CPU Topology in More Detail

To see how Linux maps logical CPUs to cores, sockets, and NUMA nodes, use lscpu -e. This is useful when you want to distinguish logical CPU IDs from physical core IDs.

# lscpu -e=CPU,CORE,SOCKET,NODE,ONLINE

Linux also exposes CPU topology through sysfs. For example, the following files show the core ID, physical package ID, and logical CPUs that belong to the same SMT sibling group as CPU0.

# cat /sys/devices/system/cpu/cpu0/topology/core_id
# cat /sys/devices/system/cpu/cpu0/topology/physical_package_id
# cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

If thread_siblings_list shows two logical CPU numbers, those logical CPUs are hardware threads associated with the same physical core. The exact CPU numbering and topology depend on the system.

How SMT (Simultaneous Multithreading) Works

SMT stands for Simultaneous Multithreading. It allows a single physical core to be used as multiple logical CPUs. Hyper-Threading, used in Intel CPUs, is a well-known implementation of SMT.

SMT Exposes One Physical Core as Multiple Logical CPUs

A four-core, eight-thread CPU, for example, contains four physical cores. The OS recognizes each core as two logical CPUs.

Linux therefore sees eight logical CPUs, each of which can be used as a target for task execution.

However, this does not mean there are eight physical cores.

Why Can One Physical Core Execute Multiple Threads?

Even while a CPU core is executing instructions, not all of its execution resources are always in use. Waiting for memory, dependencies between instructions, branches, and other factors can leave some resources idle.

With SMT, one physical core maintains the execution state of several hardware threads. Instructions from another thread can therefore use execution resources that the first thread cannot fully utilize on its own.

SMT is not simply a mechanism that switches to Thread B only when Thread A stops completely. It improves resource utilization inside a core by concurrently processing instructions from multiple hardware threads on the same physical core.

Enabling SMT Does Not Add Physical Cores

Even if SMT doubles the logical CPU count, it does not double the physical core count.

Logical CPUs belonging to the same physical core share various resources inside that core. Which resources are shared or partitioned depends on the CPU’s microarchitecture.

Therefore, 4 Physical Cores / 8 Logical CPUs ≠ 8 Physical Cores.

In other words, SMT does not increase the number of CPU cores; it enables multiple threads to use a physical core’s execution resources more efficiently.

How Much Can SMT Improve Performance?

Enabling SMT lets one physical core execute multiple hardware threads, but performance does not simply double. Threads on the same physical core share some of the core’s execution resources.

The performance benefit of SMT varies significantly depending on the CPU microarchitecture and workload. A workload may benefit when one hardware thread can use execution resources that another thread is not fully utilizing. If sibling threads compete heavily for the same resources, however, the improvement may be small and performance can even be affected negatively for some workloads.

It is therefore helpful to think of SMT not as a way to double physical cores, but as a mechanism for improving overall CPU throughput by allowing multiple hardware threads to share and use a physical core’s resources more efficiently. Measure the actual workload rather than assuming a fixed performance gain.

Why Multicore Performance Does Not Simply Increase N-Fold

An eight-core CPU does not necessarily deliver eight times the performance of a single-core CPU. Improving performance with multiple cores requires parallelizable work and relatively small limitations from shared resources and synchronization.

Some Work Cannot Be Parallelized

Some parts of a workload cannot proceed until earlier results are available. Such work cannot simply be split across multiple cores. A single-threaded application’s thread also executes on only one logical CPU at any given instant.

If only part of a workload can be parallelized, adding cores shortens the parallel portion, but the serial portion remains. This places an upper limit on the performance gain from additional cores. This relationship is known as Amdahl’s law.

CPU Caches May Be Shared

A typical multicore CPU gives each core its own L1 and L2 caches and shares L3 cache among several cores. When many cores access large amounts of data simultaneously, they may compete for shared cache capacity and bandwidth.

Frequent updates by multiple cores to data in the same cache line also increase communication needed to maintain cache coherency. Contention caused by different variables residing in the same cache line is called false sharing and can severely degrade multithreaded performance.

Cores Compete for Memory Bandwidth

Adding CPU cores does not necessarily increase main-memory transfer capacity by the same proportion. Memory bandwidth can become a bottleneck when multiple cores read and write large amounts of data simultaneously.

For workloads dominated by memory accesses rather than computation, adding cores may increase time spent waiting for data and provide little additional performance. In such cases, inspect cache misses and memory bandwidth as well as CPU utilization and core count.

Lock Contention Can Occur

Multiple threads may use locks, such as mutexes, to update shared data safely. If other threads must wait while one thread holds a lock, that portion of the workload cannot run in parallel.

If adding threads increases how often they compete for the same lock, more cores may simply produce more lock waiting rather than better performance. In some cases, performance becomes worse than before the thread count was increased.

CPU Migration Can Occur

Load balancing across CPUs has the benefit of making use of idle CPUs. However, frequent task migration between cores may require data to be loaded into the destination core’s caches, increasing cache misses.

CPU affinity can reduce migration, but restricting execution targets may also increase load imbalance. Evaluate its effects on application latency and throughput rather than focusing only on reducing migration counts.

SMT Shares Execution Resources

Logical CPUs provided by SMT are not fully independent physical cores. Hardware threads on the same physical core share its execution resources. A four-core, eight-thread CPU exposing eight logical CPUs therefore does not have the same performance characteristics as a CPU with eight physical cores.

Performance with SMT enabled varies by workload. Distinguish physical core count, logical CPU count, and task characteristics, and measure actual processing time and throughput.

Conclusion

A multicore CPU contains multiple physical cores, while Linux schedules tasks on logical CPUs. With SMT enabled, one physical core can appear as multiple logical CPUs, so the CPU(s) value shown by lscpu does not necessarily equal the number of physical cores.

More cores or logical CPUs also do not guarantee proportional performance gains. Serial processing, cache and memory behavior, lock contention, CPU migration, and resource sharing between SMT siblings can all limit scaling.

When analyzing Linux CPU performance, distinguish sockets, physical cores, hardware threads, and logical CPUs, then evaluate application parallelism and contention for shared resources. CPU topology tells you what processing resources are available; workload measurement tells you how effectively they are being used.