Migrate to RunxBuild and earn up to $50 in hosting credit on your first deposit.

Calculate your savings
unxBuild
Log in Get Started
Back to Blog Tutorial

Linux CPU Info: Read /proc/cpuinfo Without the Headache

Sean

Platform Writer

Jun 30, 2026
5 min read

Linux CPU info lives in /proc/cpuinfo, lscpu, and /sys/devices/system/cpu. The fields that matter: model name, cpu MHz, cores, cache size, virtualization features.

Linux CPU Info: Read /proc/cpuinfo Without the Headache

Table of contents

The three sources

Each source has a different shape:

  • /proc/cpuinfo is the raw kernel view. One block per logical CPU. The fields are cryptic (vendor_id, model name, cpu MHz, cache size, flags).
  • lscpu is the formatted summary. The right tool for “what CPU is this host”.
  • /sys/devices/system/cpu is the sysfs view. The right tool for scripting.

The team that needs a quick answer uses lscpu. The team that needs to parse the data in a script uses /proc/cpuinfo (with awk or grep).

Reading /proc/cpuinfo

The file has one block per logical CPU. Each block has 50+ fields. The fields that matter for most teams:

  • processor: The logical CPU number (0, 1, 2, …).
  • model name: The CPU model (“Intel(R) Xeon(R) CPU @ 2.60GHz”).
  • cpu MHz: The current CPU frequency (varies with turbo boost).
  • cache size: The L3 cache size.
  • cpu cores: The number of physical cores per socket.
  • siblings: The number of logical CPUs (including hyperthreading).
  • flags: The CPU features (vmx for Intel VT-x, svm for AMD-V, aes, avx, etc.).

The team that wants to count the physical cores uses grep -c '^processor' /proc/cpuinfo (this gives logical CPUs, including hyperthreading) or lscpu | grep "Core(s) per socket".

Using lscpu

The right tool for a human-readable summary:

$ lscpu
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) Silver 4310 CPU @ 2.10GHz
  CPU family:            6
  Model:                 106
  Thread(s) per core:    2
  Core(s) per socket:    8
  Socket(s):             1
  Caches (sum of all):
    L1d:                 384 KiB (8 instances)
    L1i:                 256 KiB (8 instances)
    L2:                  10 MiB (8 instances)
    L3:                  24 MiB (1 instance)

The fields that matter: CPU(s), Core(s) per socket, Socket(s), Thread(s) per core. The team that multiplies these gets the total logical CPU count.

The flags field

The flags field is the CPU features available. The flags that matter for virtualization:

  • vmx: Intel VT-x (hardware-assisted virtualization).
  • svm: AMD-V (AMD’s equivalent).

The flags that matter for cryptography:

  • aes: AES-NI hardware-accelerated AES.
  • sha_ni: SHA extensions.

The flags that matter for SIMD:

  • avx, avx2, avx512: AVX SIMD instructions.
  • sse4_2: SSE4.2 SIMD.

The team that checks for vmx or svm is verifying the host can run virtual machines. The team that checks for aes is verifying TLS can use hardware-accelerated AES.

What usually breaks

The four pitfalls:

  • Confusing cores and threads. nproc returns logical CPUs (with hyperthreading); lscpu shows both. The team that uses nproc to size the workload might be using 2x the physical cores.
  • Confusing the model name. Different generations of the same model have different performance. The team that picks a CPU by model name alone might miss the generation.
  • Assuming the MHz is constant. Modern CPUs vary their frequency based on load and thermal limits. cpu MHz from /proc/cpuinfo is a snapshot, not the max.
  • Reading the wrong file. /proc/cpuinfo is per-CPU; /sys/devices/system/cpu/cpu*/topology/ is more detailed but harder to parse.

The performance tuning

The right way to use CPU info for performance tuning:

  • CPU-intensive workloads benefit from higher clock speed. The team that has a single-threaded workload looks for CPUs with high base frequency.
  • Multi-threaded workloads benefit from more cores. The team that has a parallelizable workload looks for CPUs with many cores.
  • Cache-sensitive workloads benefit from larger L3 cache. The team that has a database or in-memory cache looks for CPUs with large L3.

The right tuning process:

  1. Identify the bottleneck. Use top, perf, or vtune to find what’s slow.
  2. Match CPU choice to workload. Single-threaded = high frequency; multi-threaded = many cores; cache-sensitive = large L3.
  3. Right-size the instance. Don’t pay for 64 cores if your workload uses 4.
  4. Measure after the change. Verify the new instance actually performs better.

The team that uses this process picks the right instance type for the workload. The team that picks a “big” instance “just in case” wastes money.

The NUMA angle

On multi-socket systems, NUMA (Non-Uniform Memory Access) matters:

  • Single-threaded workload on a NUMA system. The team that pins the process to one socket and one core gets consistent performance.
  • Multi-threaded workload across sockets. The team that distributes threads across sockets gets more total throughput but pays the NUMA latency penalty for cross-socket memory access.

Check NUMA topology with numactl --hardware. The team that understands their NUMA topology tunes process placement for performance.

On cloud VMs, NUMA is usually not visible (the cloud abstracts it). On bare metal or large VMs (32+ cores), NUMA matters.

FAQ

How do I check the CPU on Linux?

lscpu for a summary, cat /proc/cpuinfo for the raw data. The team that wants the logical CPU count uses nproc.

How many physical cores do I have?

lscpu | grep "Core(s) per socket" gives the cores per socket. Multiply by the number of sockets (Socket(s) line) for the total physical cores.

What does the flags field mean?

CPU features available. vmx or svm for virtualization, aes for hardware AES, avx/avx2/avx512 for SIMD. The team that wants to know if the host can run VMs checks for vmx or svm.

Why does my CPU MHz change?

Modern CPUs use turbo boost and thermal throttling. The MHz varies based on load and temperature. The team that needs the consistent frequency looks at the base frequency, not the current MHz.

How do I know if my CPU is hyperthreaded?

lscpu | grep "Thread(s) per core". If the value is 2, hyperthreading is enabled. The team that has a workload that benefits from hyperthreading (most multi-threaded workloads) leaves it on; the team that has a workload that doesn’t (some high-performance computing) disables it in the BIOS.

What’s the difference between cores and threads?

A core is a physical CPU. A thread is a logical CPU that the OS sees. With hyperthreading, each physical core has 2 threads. The team that uses nproc gets logical CPUs (threads); the team that uses lscpu gets both.

Can I disable specific CPU cores?

Yes, with echo 0 > /sys/devices/system/cpu/cpu<N>/online. Useful for benchmarking (isolate a workload to specific cores). The team that uses this for production performance tuning measures the difference carefully.

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:

#linux#cpu#/proc/cpuinfo#lscpu#diagnostic