For a CPU summary, use lscpu. For per-core detail, read /proc/cpuinfo. For a count, use nproc. The three commands answer three different questions. The team that picks the right one for the question has the answer in under a second. The team that does cat /proc/cemifo | grep name | uniq every time is wasting keystrokes.
Table of contents
- The lscpu command: the right answer for most questions
- The /proc/cpuinfo file: per-core detail
- The nproc command: just the count
- Reading CPU frequency in real time
- NUMA topology and which CPU is which
- FAQ
The lscpu command: the right answer for most questions
The lscpu command is the canonical tool for CPU information on Linux. It reads from sysfs, /proc/cpuinfo, and any architecture-specific libraries, then formats the data into a readable summary. The default output looks like:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
CPU family: 6
Model: 79
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
...
Caches (sum of all):
L1d: 256 KiB (8 instances)
L1i: 256 KiB (8 instances)
L2: 2 MiB (8 instances)
L3: 35 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-15The fields that matter: Architecture (x86_64, aarch64), Model name (the actual SKU), CPU(s) (total logical processors), Core(s) per socket (physical cores), Thread(s) per core (hyperthreading), Socket(s) (the physical CPUs). The math is CPU(s) = Socket(s) × Core(s) per socket × Thread(s) per core. In the example above, 1 × 8 × 2 = 16, which matches CPU(s). The right way to read a CPU spec is to look at all three numbers separately, not just the total.
The NUMA section at the bottom is the topology. A single-socket system has one NUMA node, and all CPUs are in node 0. A two-socket system has two NUMA nodes, and the right answer for performance-critical workloads is to pin processes to the right socket.
The /proc/cpuinfo file: per-core detail
The /proc/cpuinfo file is the raw data that lscpu reads from. The right use case is per-core detail — for example, checking the frequency of a specific core, or seeing the flags that each core supports. The file has one block per logical processor, separated by blank lines. A typical block:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 79
model name : Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
stepping : 1
microcode : 0xb000038
cpu MHz : 1200.000
cache size : 35840 KB
physical id : 0
siblings : 16
core id : 0
cpu cores : 8
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr ...
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management: ts ttp tm hwp hwp_act_window hwp_epp ...The fields that matter: cpu MHz is the current frequency, not the max. The CPU may be at 1200 MHz because the governor has it down-clocked for power saving. To see the max, look at model name (the rated frequency) or read /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq. The flags line is the full CPU feature set — sse4_2, avx, avx2, aes, etc. The right answer for checking if a workload can use a specific instruction is to grep the flags.
The right one-liner to get just the model name:
grep -m1 'model name' /proc/cpuinfo | cut -d: -f2The right one-liner to count the CPUs:
grep -c ^processor /proc/cpuinfoThe right one-liner to list the unique flags:
awk '/^flags/{for(i=2;i<=NF;i++)print $i}' /proc/cpuinfo | sort -uThe nproc command: just the count
The nproc command prints the number of processing units available to the current process. The default output is just a number:
16The nproc command respects cgroup limits in containers. Inside a container with --cpuset-cpus or --cpushares, nproc returns the number of CPUs the container is allowed to use, not the host’s total. The right answer for a containerized workload is to use nproc (or lscpu) and trust the result. The wrong answer is to look at the host’s /proc/cpuinfo and assume the container has the same.
The right one-liner to set a Make job pool size based on available CPUs:
make -j$(nproc)The right one-liner to set a parallel script’s worker count:
workers=$(nproc)Reading CPU frequency in real time
The cpu MHz in /proc/cpuinfo is a snapshot at boot. The current frequency is in /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq. The right one-liner to see all the current frequencies:
paste <(cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq) <(echo) | column -tOr, more usefully, as a watch loop:
watch -n 1 "cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq | uniq -c"The frequency varies based on the governor (performance, powersave, ondemand, schedutil, conservative). The right answer for a latency-sensitive workload is the performance governor, which keeps the CPU at the max frequency. The right answer for a power-constrained workload is the default governor (usually schedutil or ondemand on a modern system), which scales up only under load.
To set the governor:
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorThe right permanent change is in /etc/default/cpufrequtils or via the intel_pstate configuration. The wrong answer is to set the governor in /sys/ and expect it to persist across reboots — it does not.
NUMA topology and which CPU is which
On a multi-socket server, lscpu shows the NUMA topology. A two-socket system has two NUMA nodes, and the right answer for performance-critical workloads is to pin processes to the right socket. The right tool is numactl:
numactl --hardwareThe output shows the NUMA nodes, the CPUs in each node, and the memory attached to each node. To pin a process to NUMA node 0:
numactl --cpunodebind=0 --membind=0 my-processThe right answer for a database or other latency-sensitive workload is to pin it to one NUMA node. The right answer for a throughput workload is to let the kernel’s automatic NUMA balancing decide. The wrong answer is to spread a single-threaded process across multiple NUMA nodes — the inter-node latency is much higher than the intra-node latency.
FAQ
My CPU shows 1 core but lscpu says 8. What is wrong?
Nothing is wrong. nproc (which prints the cpu cores value in some outputs) and lscpu may show different numbers depending on which field they default to. The right answer is to look at all three: Socket(s) × Core(s) per socket × Thread(s) per core. A system with 1 socket, 4 cores per socket, and 2 threads per core has 8 logical processors (nproc) but 4 physical cores (lscpu | grep 'Core(s) per socket').
Can I see the temperature?
Yes, but it requires the lm-sensors package. sudo sensors-detect configures it (walk through the prompts, accept the defaults), then sensors shows the current temperatures, fan speeds, and voltages. The right answer for thermal monitoring in a server is lm-sensors plus a metrics exporter (node_exporter has a built-in collector) so the data goes to Prometheus or similar.
How do I know if the CPU is 64-bit?
lscpu | grep Architecture shows the architecture. x86_64, aarch64, and ppc64le are the 64-bit variants on the three common server architectures. The wrong answer is to look at the kernel name (uname -m) without context — uname -m returns the architecture the kernel was built for, not the architecture of the underlying hardware.
Why does the model name show @ 2.40GHz but the actual MHz is 1200?
Power management. The model name field is the rated frequency; the cpu MHz field is the current frequency. On a modern CPU with speed boost or speed scaling, the actual frequency varies based on the workload, the temperature, and the governor. The right answer for a benchmark is to set the governor to performance and disable turbo boost, so the result is reproducible.
Can I see which process is using which CPU?
Yes. top shows the per-process CPU usage. htop is more user-friendly. For a per-thread view, htop -t or ps -eLf. The right answer for a quick sanity check is top, the right answer for a deep investigation is perf top (from the linux-tools package), which shows which kernel and user-space functions are hot.
What about ARM CPUs?
The same commands work. lscpu shows the architecture (aarch64), the model (Cortex-A72, Neoverse-N1, etc.), and the topology. The flags line is different — ARM CPUs have asimd, aes, sha1, sha2 instead of sse4_2, avx, avx2. The right answer for an ARM box is the same workflow as x86: lscpu for the summary, /proc/cpuinfo for per-core, nproc for the count.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: