VMware ESXi and vSphere Cluster Management

How to Identify CPU Information in Linux

Learn how to identify Linux CPU models, architecture, cores, threads, cache, frequency, topology, and CPU features with /proc/cpuinfo, uname, and lscpu.

Why identify CPU information?

The CPU, or central processing unit, executes program instructions. Knowing its model and capabilities helps you select compatible software, investigate performance, plan virtualization, document hardware, and verify whether a system supports a required instruction set.

Linux exposes CPU information through the kernel and through utilities that format or interpret that information. The most useful starting points are the virtual file /proc/cpuinfo, the uname command, and lscpu.

Procfs is the virtual filesystem mounted at /proc. It does not normally store ordinary files on disk. Instead, the kernel generates information such as process, memory, and processor data when programs read it.

Important CPU terms

  • CPU architecture: The processor instruction-set family and machine type, such as x86_64 or aarch64.
  • Instruction set architecture (ISA): The machine instructions supported by a processor architecture.
  • Logical CPU: A processor execution unit visible to Linux, often called a hardware thread.
  • Physical core: A processing core physically present inside a CPU package.
  • Socket: A physical CPU package or processor location recognized by the system.
  • Threads per core: The number of logical CPUs exposed by each physical core. SMT, or simultaneous multithreading, can expose more than one.
  • Cache: Fast memory close to the CPU, commonly divided into L1, L2, and L3 levels.
  • CPU frequency: The processor clock rate, usually shown in MHz or GHz. It can change dynamically.
  • NUMA: Non-uniform memory access, a design in which memory access time can differ depending on the CPU node using it.

Inspect raw details with /proc/cpuinfo

The virtual file /proc/cpuinfo contains processor details supplied by the running Linux kernel. Display it with:

cat /proc/cpuinfo

On many x86 systems, the output is divided into repeated blocks. Each block usually describes one logical CPU visible to the operating system, not necessarily one physical core. A machine with four physical cores and two threads per core may therefore contain eight processor blocks.

Common /proc/cpuinfo fields

  • processor: The logical CPU number, commonly starting at zero.
  • vendor_id: The processor vendor identifier on architectures that provide it.
  • model name: A human-readable CPU model on many x86 systems.
  • cpu family, model, and stepping: Numeric identification details used mainly for processor-family and revision identification.
  • cpu MHz: A reported frequency value. It may be current or sampled and can change with power management.
  • cache size: A cache-size value, often representing a particular cache level rather than every cache level.
  • physical id: An identifier for a physical processor package when the architecture and platform expose it.
  • core id: An identifier for a physical core within a package when available.
  • siblings: The number of logical CPUs associated with a package in formats that provide this field.
  • cpu cores: The number of physical cores associated with a package in formats that provide this field.
  • flags: Processor capabilities and instruction-set extensions, such as sse4_2, avx, avx2, aes, vmx, svm, and hypervisor.
  • address sizes: Supported physical and virtual address widths on systems that report them.
  • bogomips: A kernel-calculated calibration value. It is not a reliable measure of real application performance or CPU speed.

Fields vary by CPU architecture, kernel version, physical platform, and virtual machine implementation. For example, an ARM system may use fields such as Hardware, CPU implementer, or CPU architecture instead of model name.

Filter the output

To display one model-name line instead of one line for every logical CPU, use:

grep -m1 'model name' /proc/cpuinfo

To count visible logical CPU entries on systems that use processor entries:

grep -c '^processor' /proc/cpuinfo

To search for model and architecture fields across systems with different naming conventions:

grep -iE '^(model name|hardware|cpu model|processor|architecture)' /proc/cpuinfo

To check whether a particular feature is exposed:

grep -wo 'avx2' /proc/cpuinfo | head

A missing feature can mean that the CPU does not support it, firmware has disabled it, or a hypervisor is masking it from a guest system.

Check architecture with uname

The uname command reports information about the running kernel and machine. The most useful architecture check is:

uname -m

uname -m reports the machine architecture used by the running kernel. It does not identify the exact processor model.

uname -p requests a processor-type value:

uname -p

On some Linux distributions and systems, uname -p returns unknown. Treat it as an optional processor-type query, not as the primary architecture check. Use uname -m for architecture and lscpu or /proc/cpuinfo for model and topology details.

Common architecture values

Reported value | General processor family | Typical use or platform

x86_64 | 64-bit x86 | Most modern Intel and AMD desktops, servers, and laptops

i686 | 32-bit x86 | Older or specially configured 32-bit x86 systems

aarch64 | 64-bit ARM | ARM servers, development boards, and many modern ARM systems

armv7l | 32-bit ARM | Older ARM boards and embedded systems

ppc64le | Little-endian 64-bit Power | Certain enterprise and high-performance Power systems

s390x | 64-bit IBM Z | IBM mainframe Linux systems

The architecture value describes the running kernel's machine type and ISA family. It is not a complete description of the physical CPU model.

Use lscpu for a structured summary

lscpu is provided by the util-linux package. It reads kernel interfaces and presents a readable summary of architecture, CPU topology, cache, virtualization, and related information.

lscpu

A typical summary can include architecture, supported CPU operating modes, byte order, total visible CPUs, the online CPU list, threads per core, cores per socket, sockets, NUMA nodes, vendor ID, model name, frequency limits, cache sizes, virtualization, and vulnerability information.

Some values are calculated from topology data. For example, the displayed logical CPU count can be related to sockets, cores per socket, and threads per core, but restrictions from a VM, container, CPU set, CPU affinity, or hot-plug state can make the visible count differ from installed host hardware.

Useful lscpu formats

  • lscpu -e or lscpu --extended displays extended per-logical-CPU information, helping map logical CPUs to cores, sockets, and NUMA nodes.
  • lscpu -p produces parseable output suitable for scripts. Comment lines may appear at the beginning, so scripts should account for them.
  • lscpu -J produces JSON output on versions that support this option, which is useful for automation.
  • lscpu --all requests information for all CPUs where the installed version and environment support that behavior. It is useful when distinguishing available CPUs from currently online CPUs.

Interpreting common lscpu fields

Field | Meaning | Example interpretation | Common misunderstanding

Architecture | Kernel machine architecture | x86_64 means 64-bit x86 | It does not name the exact CPU model

CPU(s) | Logical CPUs visible to the system | 16 means 16 visible execution units | It does not necessarily mean 16 physical cores

On-line CPU(s) list | Logical CPUs currently online | 0-15 means all 16 listed CPUs are online | Installed or possible CPUs may be different

Thread(s) per core | Logical CPUs exposed by each physical core | 2 commonly indicates SMT | It is not the number of software threads a program can create

Core(s) per socket | Physical cores in each CPU package | 8 means eight cores per listed socket | It is not the total core count when multiple sockets exist

Socket(s) | Physical processor packages recognized by Linux | 2 indicates a two-socket topology | A VM may present virtual sockets rather than host packages

Vendor ID | Processor vendor identifier | An x86 vendor string identifies a vendor family | It is not a marketing model name

Model name | Human-readable processor model | A specific Intel, AMD, or other model string | Virtual machines may expose a generic or masked name

CPU max MHz and CPU min MHz | Reported frequency limits | The range within which policy or hardware may operate | Neither necessarily equals the current frequency

L1d, L1i, L2, and L3 cache | Data, instruction, and larger cache levels | L1d is level-one data cache; L3 is a larger shared cache on many CPUs | Cache totals and sharing can be presented differently by tool versions

NUMA node(s) | Number of memory-locality nodes | Multiple nodes indicate a NUMA topology | It is not another name for CPU sockets

Virtualization | Reported virtualization capability or guest status | VT-x, AMD-V, or a hypervisor indicator | A guest may not see all host capabilities

Understand CPU topology

CPU topology describes how logical CPUs relate to physical hardware. A common calculation is:

logical CPUs = sockets × cores per socket × threads per core

For example, two sockets with eight cores per socket and two threads per core expose up to 32 logical CPUs:

2 × 8 × 2 = 32 logical CPUs

This estimate assumes all components are enabled and visible. SMT may expose two logical CPUs per physical core, but logical CPUs share many resources within the core and do not provide the same performance as separate physical cores.

Use the topology summary with:

lscpu -e

The extended output can show each logical CPU's core, socket, and NUMA-node relationship. This is useful when investigating CPU affinity, thread placement, or multi-socket performance.

Read CPU flags and compatibility features

CPU flags are reported capabilities and ISA extensions. They can indicate whether software may use specialized instructions, but a flag check alone does not guarantee that an application, operating system, compiler, or virtual machine will use them.

  • sse4_2: An extension of the SSE instruction family.
  • avx: Advanced Vector Extensions for vector operations.
  • avx2: A later AVX extension with additional integer and vector capabilities.
  • aes: Hardware support for AES-related instructions on systems that report this x86 feature.
  • vmx: Intel hardware virtualization extensions.
  • svm: AMD hardware virtualization extensions.
  • hypervisor: Commonly indicates that the operating system is running under a hypervisor.

Feature names are architecture-specific. ARM, Power, IBM Z, and other architectures use different naming conventions, so do not assume that x86 flag names exist everywhere.

Compare the primary methods

Command | Primary purpose | Key information shown | Best use case | Limitations

cat /proc/cpuinfo | Read raw kernel-provided processor details | Model, flags, cache, frequency, topology-related fields | Detailed inspection and quick shell filtering | Repeated entries, architecture-specific fields, and less convenient formatting

uname -m | Report machine architecture | Kernel architecture such as x86_64 or aarch64 | Fast software compatibility check | Does not identify the exact CPU model or topology

uname -p | Request processor type | A processor-type value where supported | Occasional supplementary check | May return unknown and is not a dependable architecture test

lscpu | Present a structured summary | Architecture, counts, topology, cache, frequency, virtualization, vulnerabilities | Human-readable system inventory and troubleshooting | Interpretation depends on kernel, util-linux version, and virtualization exposure

lscpu -e | Show extended per-CPU topology | Logical CPU to core, socket, and node relationships | Topology, affinity, and NUMA investigation | Output columns vary by version and available data

Filtered /proc/cpuinfo queries | Select specific raw fields | Model, processor entries, flags, or architecture fields | Small scripts and focused terminal checks | Field names and repetition vary across architectures

These commands can legitimately show different results because they report different layers. uname focuses on the running kernel's machine type, /proc/cpuinfo exposes raw kernel-formatted data, and lscpu normalizes and interprets topology and related sources.

Troubleshooting CPU identification

uname -p returns unknown

This usually means the kernel or distribution does not provide a meaningful processor-type value for that option. Use uname -m for architecture, then use lscpu or /proc/cpuinfo for model and topology.

The model name is missing

The field may not exist on a non-x86 architecture, the kernel may expose different field names, or a virtual machine may provide limited information. Try:

lscpu
grep -iE '^(model name|hardware|cpu model|processor|architecture)' /proc/cpuinfo

The CPU count is higher than expected

Compare logical CPUs with physical cores. Check Thread(s) per core, Core(s) per socket, and Socket(s) in lscpu. SMT or hyperthreading commonly explains a larger logical CPU count.

The CPU count is lower than the installed hardware

A VM may have only a subset of host CPUs. Containers can be restricted by cpusets, and CPU affinity can limit individual processes. CPUs may also be offline. Check:

lscpu
lscpu -e

Pay particular attention to CPU(s) and On-line CPU(s) list, then review the VM allocation or container and cpuset configuration.

The reported MHz value changes

Dynamic frequency scaling, turbo behavior, power management, and idle states cause frequency to change. Different tools may report a current sample, a minimum, a maximum, or a policy limit. Do not use one instantaneous MHz value as the sole basis for benchmark conclusions.

A feature such as AVX or virtualization is absent

The hardware may not support it, firmware may have disabled it, or a hypervisor may be masking it from a guest. Inspect flags in /proc/cpuinfo and the virtualization-related lines in lscpu. In a physical system, review firmware settings; in a VM, review the virtual CPU feature configuration.

A practical identification workflow

  1. Run uname -m to identify the running kernel architecture.
  2. Run lscpu for a readable summary of model, logical CPUs, topology, cache, frequency limits, and virtualization.
  3. Run lscpu -e when you need the relationship between logical CPUs, cores, sockets, and NUMA nodes.
  4. Read cat /proc/cpuinfo when you need raw fields or architecture-specific flags.
  5. Use targeted grep commands to collect one model line, count logical CPUs, or test a particular feature.

For a quick compatibility check, combine the architecture and model summary:

uname -m
lscpu | grep -E 'Architecture|Model name|CPU\(s\)|Thread|Core|Socket|Virtualization'

For more details about identifying related Linux hardware, continue with CPU identification in Linux and apply the same distinction between raw kernel data, normalized utilities, and hardware exposed through virtualization.

Exam-relevant notes

  • uname -m is the preferred quick architecture check; uname -p may return unknown.
  • Repeated /proc/cpuinfo blocks generally represent logical CPUs.
  • Logical CPU count is not the same as physical-core count.
  • Use sockets, cores per socket, and threads per core to understand topology.
  • CPU frequency is dynamic and should be interpreted as a time-dependent or policy-dependent value.
  • CPU flags describe exposed capabilities, but virtualization can hide host features.
  • Fields in /proc/cpuinfo differ across architectures and environments.