Mapping the Silicon
Think of a modern server CPU the way you would think of a large office building. The building has multiple floors (sockets), each floor has multiple rooms (cores), and each room can hold two workers at once (hyperthreads). The building also has shared filing cabinets on each floor (L3 cache) and private drawers in each room (L1/L2 cache). If a worker on floor 1 needs a file stored in a cabinet on floor 2, they have to walk across the building — that takes time. This physical distance is the essence of NUMA (Non-Uniform Memory Access), and it is one of the most common sources of unexplained latency in high-performance systems.
1. The Text Summary: lscpu
lscpu reads from /sys/devices/system/cpu/ and /proc/cpuinfo and presents a structured summary — no special privileges required to run it.
Key fields to understand:
| Field | What it means |
|---|---|
Socket(s) |
Number of physical CPU chips on the motherboard |
Core(s) per socket |
Physical processing units per chip |
Thread(s) per core |
Hyperthreading multiplier. 2 means the OS sees 2 logical CPUs per physical core |
NUMA node(s) |
Number of memory domains. More than 1 means cross-node memory access is slower |
NUMA node0 CPU(s) |
Which logical CPUs belong to NUMA node 0 |
L1d/L1i/L2/L3 cache |
Cache sizes. L3 is shared across cores in a socket |
A typical dual-socket server with 8 cores per socket and hyperthreading enabled will show: Socket(s): 2, Core(s) per socket: 8, Thread(s) per core: 2, giving CPU(s): 32 total logical CPUs.
2. The Visual Map: lstopo
lstopo is part of the hwloc (Hardware Locality) package. Where lscpu gives you numbers, lstopo gives you a spatial diagram that makes the relationships between components immediately obvious. It can render as plain text (useful over an SSH session with no display) or as a graphical image when one is available — either way, the payoff is a picture of the socket/core/cache hierarchy instead of a flat list of numbers.
What lstopo reveals that lscpu does not:
- PCI device locality: Your 10 GbE network card or NVMe drive is physically connected to one specific CPU socket via the PCIe bus. If your network-processing application runs on cores belonging to the other socket, every packet crosses the inter-socket interconnect (QPI/UPI), adding latency and consuming bandwidth on that link.
- Cache sharing boundaries: You can see exactly which cores share an L3 cache. Threads that communicate frequently should be pinned to cores sharing an L3 cache to avoid cache-miss penalties.
- Memory channel layout: On some systems,
lstoposhows which memory DIMMs are attached to which socket.
Why this matters for performance tuning: The practice of binding a process to specific CPUs and memory nodes is called CPU affinity and NUMA binding. Tools like taskset (set CPU affinity) and numactl (set both CPU and memory affinity) use the topology information that lstopo visualises. Without understanding the topology first, you are tuning blind.
A common SRE interview question is: "A latency-sensitive application is running on a dual-socket server and showing inconsistent tail latency. Where do you start?" The expected answer involves NUMA: check whether the process is migrating between sockets (causing remote memory access), use lstopo to understand the topology, then pin the process with numactl --cpunodebind=0 --membind=0 ./app. Interviewers are testing whether you know that latency problems are not always about CPU load — they can be about physical distance on the motherboard.