Linux CPU info: lscpu, /proc/cpuinfo, nproc and CPU temperature

Short answer: to get CPU info on Linux, run lscpu. It shows the CPU model, architecture, number of CPUs, sockets, cores per socket, threads per core, caches, NUMA layout and feature flags. nproc prints just the number of CPUs you can use, /proc/cpuinfo holds the raw detail per CPU, and sensors shows the temperature on bare metal.

lscpu                                    # everything in one summary
nproc                                    # how many CPUs this shell may use
grep -m1 'model name' /proc/cpuinfo      # just the model
lscpu | grep -E 'Model name|Socket|Core|Thread|NUMA node\(s\)|Virtualization|Hypervisor'
sensors                                  # temperatures (bare metal, after installing lm-sensors)

lscpu (util-linux 2.38.1), nproc (GNU coreutils 9.1), /proc/cpuinfo and the glibc check further down were run on Debian 12 in a KVM guest on 21 October 2026; the example outputs are shortened and their values illustrative. dmidecode, lm-sensors and cpupower are written from their man pages, because a virtual machine has no real firmware tables, sensors or frequency driver to show, and the PowerShell part from Microsoft’s documentation.

Cheat sheet: CPU information by question

How do I read lscpu?

Architecture:            x86_64
CPU op-mode(s):          32-bit, 64-bit
Address sizes:           46 bits physical, 48 bits virtual
CPU(s):                  4
On-line CPU(s) list:     0-3
Vendor ID:               GenuineIntel
BIOS Vendor ID:          QEMU
Model name:              Intel Xeon Processor (Cascadelake)
Thread(s) per core:      1
Core(s) per socket:      4
Socket(s):               1
Flags:                   fpu vme de pse tsc msr pae ... aes ... avx2 ... avx512f ... hypervisor ...
Hypervisor vendor:       KVM
Virtualization type:     full
L1d cache:               128 KiB (4 instances)
L2 cache:                16 MiB (4 instances)
L3 cache:                64 MiB (4 instances)
NUMA node(s):            1
NUMA node0 CPU(s):       0-3

This is the flat Field: value layout that lscpu always prints into a pipe, so grep sees these names. On a terminal, newer versions may group some lines under headings such as Caches (sum of all):, with shorter names like L1d:; lscpu | less shows the flat form.

How cores and threads relate, and what a vCPU is, has its own guide: CPU cores vs threads. Two things are specific to a virtual machine. Model name is the real host CPU only when the hypervisor passes it through; otherwise it is a named model such as Intel Xeon Processor (Cascadelake), which carries that generation’s features but says nothing about the exact chip. And cache lines can look odd: in the Debian 12 guest used for this page, lscpu reported the L3 cache once per vCPU, because the virtual topology gave every vCPU an L3 of its own.

For a per-CPU view, lscpu -e lists every logical CPU with its node, socket, core and cache IDs; lscpu -C lists the caches with their size, ways and level; and lscpu -J prints the summary as JSON for scripts.

What is in /proc/cpuinfo?

/proc/cpuinfo is the kernel’s raw description, with one block per logical CPU. lscpu summarises it; reading it directly is handy in scripts and on minimal systems without util-linux.

grep -m1 'model name' /proc/cpuinfo              # the model
grep -c ^processor /proc/cpuinfo                 # logical CPUs
grep 'physical id' /proc/cpuinfo | sort -u | wc -l   # sockets (on bare metal)
grep -m1 '^flags' /proc/cpuinfo | cut -d: -f2 | wc -w   # how many flags

• processor: the logical CPU number, starting at 0.
• model name, vendor_id, cpu family, model, stepping, microcode: what the chip is and which microcode revision is loaded.
• physical id, core id, siblings, cpu cores: the socket and core each logical CPU belongs to.
• cpu MHz: the clock at the moment of reading (see frequency below).
• flags and bugs: supported extensions, and the CPU vulnerabilities the kernel knows apply to this chip.

On arm64 the file looks different: there is no model name line, only numeric CPU implementer and CPU part codes, which lscpu translates into a name.

How many CPUs do I have? nproc

nproc                          # CPUs this process may run on
nproc --all                    # CPUs installed
getconf _NPROCESSORS_ONLN      # CPUs online, the POSIX way
make -j"$(nproc)"              # typical use: one build job per CPU

nproc counts logical CPUs, so a 4-core CPU with Hyper-Threading reports 8. It also honours CPU affinity: a container pinned to two CPUs or a process started with taskset sees fewer than nproc --all. How a Docker CPU quota interacts with it is in the cores and threads guide.

What does dmidecode -t processor add?

sudo dmidecode -t processor | grep -E 'Socket Designation|Version|Core Count|Thread Count|Max Speed|Current Speed'

dmidecode reads the firmware’s SMBIOS tables, so it reports what the board knows: the socket name, the exact processor version string, core and thread count per socket, and the rated maximum and current speed. On a two-socket server you get two blocks, which also shows whether a socket is empty. Inside a virtual machine the tables come from the hypervisor’s virtual firmware and describe virtual sockets, so lscpu tells you as much there.

Which CPU flags matter on a server?

grep -o -w -E 'aes|avx2|avx512f|sha_ni|vmx|svm|hypervisor' /proc/cpuinfo | sort | uniq -c
# each flag is printed once per logical CPU that has it, e.g. "4 avx2" on 4 CPUs

Newer distributions also build packages for x86-64 “microarchitecture levels”: v2 requires SSE4.2 and POPCNT among others, v3 adds AVX2 and FMA, v4 adds AVX-512. Ubuntu 26.04 LTS, for example, offers an opt-in amd64v3 variant according to its release notes. glibc 2.33 and later prints which levels your CPU supports (checked here with glibc 2.36):

/lib64/ld-linux-x86-64.so.2 --help | grep supported
#   x86-64-v4 (supported, searched)
#   x86-64-v3 (supported, searched)
#   x86-64-v2 (supported, searched)

How do I see the current CPU frequency?

grep MHz /proc/cpuinfo                       # per CPU, at this moment
watch -n 1 "grep MHz /proc/cpuinfo"          # live
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq   # kHz, needs a cpufreq driver
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   # e.g. performance or powersave
sudo cpupower frequency-info                 # Debian: linux-cpupower; Ubuntu: linux-tools-$(uname -r)

On bare metal the clock changes all the time with load and power settings, and lscpu adds CPU max MHz and CPU min MHz lines. In the Debian 12 KVM guest used for this page, there was no cpufreq directory under /sys/devices/system/cpu/cpu0 and lscpu printed no MHz lines at all; cpu MHz in /proc/cpuinfo showed one fixed value. That is normal for a VM: the host decides how fast its cores run.

Load average vs number of CPUs

uptime          # load average: 0.90, 0.75, 0.85  (1, 5 and 15 minutes)
nproc           # compare the load with this number

Load counts tasks running or waiting to run (and on Linux, tasks waiting for disk). A load of 4 on 4 CPUs means every CPU is busy; on 16 CPUs it is a quiet server. A load persistently above nproc means work is queuing. To find out what is causing it, htop shows per-CPU bars and steal time, and VPS high CPU usage walks through the usual causes.

How do I check the CPU temperature?

On bare metal: lm-sensors

sudo apt install lm-sensors
sudo sensors-detect --auto       # finds and loads the right drivers
sensors                          # print all readings
watch -n 2 sensors               # refresh every 2 seconds

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +46.0°C  (high = +80.0°C, crit = +90.0°C)
Core 0:        +43.0°C  (high = +80.0°C, crit = +90.0°C)
Core 1:        +45.0°C  (high = +80.0°C, crit = +90.0°C)

Intel CPUs report through the coretemp driver (a Package id line per socket plus one line per core); AMD CPUs through k10temp, usually as Tctl and per-die Tccd values. Judge a reading against the high and crit limits the chip reports next to it, not against a number from a forum. Without lm-sensors, the kernel exposes the same data in sysfs, in thousandths of a degree:

grep . /sys/class/hwmon/hwmon*/temp*_input        # 46000 = 46.0 °C
paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp)

Why does a VPS show no CPU temperature?

Because the sensors belong to the physical machine, and the hypervisor owns it. A KVM guest gets virtual CPUs with no thermal drivers behind them: in the Debian 12 guest used for this page, /sys/class/hwmon was empty and /sys/class/thermal held only cooling-device entries, no thermal zones. So sensors answers No sensors found!, and sensors-detect finds nothing to load. That is not a fault. Cooling is the provider’s job; what you can watch from inside is CPU usage and steal time. If temperatures matter to you, for example for long encoding or compile runs, that is one more reason to run the work on a dedicated server, where the sensors are yours to read. What is KVM explains where the line between host and guest runs.

And on Windows?

Get-CimInstance Win32_Processor |
  Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, MaxClockSpeed

Task Manager shows the same under Performance, CPU, with the current speed live. Windows has no built-in temperature readout for most CPUs; that needs the board vendor’s tools on bare metal, and on a Windows VPS, as on Linux, the sensors stay with the host.

What you see on a VPS vs a dedicated server

• On a VPS, lscpu shows vCPUs, a hypervisor vendor and often a generic model name; there are no sensors or frequency lines, and contention shows up as steal time. VMHeaven’s Standard KVM runs on Intel server CPUs and Hi-CPU KVM on AMD EPYC, so a plan page tells you the platform before lscpu does.
• On a dedicated server, every command on this page reports the real hardware: sockets, cores, threads, the rated speed and the temperatures. The dedicated server pages list the CPU, memory and disks of every build in stock in Amsterdam, so you can compare them with what your software needs before you order.

Frequently asked