Read /proc/cpuinfo Without Mistaking It for a Hardware Database

A script grabs the "model name" line from /proc/cpuinfo and someone treats it as gospel, then it breaks on the next architecture. This guide covers read-only commands for inspecting the CPUs Linux exposes, counting logical processors, and extracting a value for a script, plus when to stop parsing this file and reach for lscpu instead. It follows proc_cpuinfo(5) from Linux man-pages 6.7, installed here as package version 6.7-2.

Allow about ten minutes. You need a shell on Linux. No elevated privileges are required, and nothing here changes kernel state, CPU settings or services.

1. Read the file as a set of CPU records

Start by viewing the first record:

$ sed -n '1,28p' /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 158
model name	: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
...
bogomips	: 7200.00

/proc/cpuinfo is a virtual procfs file: the kernel supplies its contents when you read it, so there's no ordinary file to edit and no useful backup to make. Its fields are architecture-dependent. The manpage calls out processor and bogomips as common entries, but a field seen on one architecture is not automatically portable to another.

On an SMP system the file normally holds one record per CPU Linux supports, separated by blank lines. The first record isn't a summary followed by details: it describes processor 0, just as later records describe processor 1 and so on.

$ test -r /proc/cpuinfo && grep -m1 '^processor' /proc/cpuinfo
processor	: 0

2. Count logical CPUs safely

If you need the number of processor records, count the lines whose key is exactly processor:

$ awk -F: '$1 ~ /^[[:space:]]*processor[[:space:]]*$/ { count++ } END { print count }' /proc/cpuinfo
8

The result is a count of logical CPUs represented in this file. On a host with simultaneous multithreading it can be greater than the number of physical cores, and it can differ from the CPUs currently available to a container or process, since scheduling limits and CPU affinity are separate concerns.

Trap: do not count every occurrence of the word processor. Architecture-specific values or descriptive text elsewhere in the file could contain similar words. Matching the key before the colon keeps this small script tied to the record structure, not a particular model name.

3. Extract a value for inspection

For a one-off check, grep is enough:

$ grep -m1 '^model name' /proc/cpuinfo
model name	: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz

To strip the label and surrounding whitespace in a script, split once at the colon:

model_name=$(awk -F: '
    $1 ~ /^[[:space:]]*model name[[:space:]]*$/ {
        sub(/^[[:space:]]+/, "", $2)
        sub(/[[:space:]]+$/, "", $2)
        print $2
        exit
    }
' /proc/cpuinfo)
printf 'CPU model: %s\n' "$model_name"

The exit matters: a single model string is usually all you want, and it stops the script printing one copy per logical CPU. On an architecture without a model name field the command prints nothing. Treat an empty result as "not reported", not as proof the machine has no identifiable processor.

$ printf 'CPU model: %s\n' "$model_name"
CPU model: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz

4. Compare records without assuming every field is identical

To see the processor numbers and model names present in each record:

awk -F: '
    /^[[:space:]]*processor[[:space:]]*:/ {
        cpu = $2
        sub(/^[[:space:]]+/, "", cpu)
    }
    /^[[:space:]]*model name[[:space:]]*:/ {
        model = $2
        sub(/^[[:space:]]+/, "", model)
        printf "CPU %s: %s\n", cpu, model
    }
' /proc/cpuinfo

On this machine that prints one line per logical CPU, useful for spotting an unexpectedly mixed virtual machine or a partial view of the records. It is not a complete topology report: physical package, core, cache and feature fields are all subject to the architecture and kernel implementation that produced the file.

5. Use lscpu when you need a summary

The proc_cpuinfo(5) manpage states that lscpu(1) gathers information from this file. Prefer it when you need a readable summary of architecture, sockets, cores, threads, address sizes or CPU lists:

$ lscpu | sed -n '1,14p'
Architecture:                            x86_64
CPU op-mode(s):                          32-bit, 64-bit
Address sizes:                           39 bits physical, 48 bits virtual
Byte Order:                              Little Endian
CPU(s):                                  8
On-line CPU(s) list:                     0-7
Vendor ID:                               GenuineIntel
Model name:                              Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
Thread(s) per core:                      2
Core(s) per socket:                      4
Socket(s):                               1

This host reports lscpu from util-linux 2.41.3 and eight logical CPUs. The summary is easier to read, but that doesn't make /proc/cpuinfo a stable machine-readable API. If a script depends on a field, check that field exists on every architecture it will run on and handle an absent value.

Common traps

• Trusting bogomips. It is a kernel-initialisation constant, not a trustworthy modern performance benchmark. Do not use it to compare hosts or choose workloads.
• Treating cpu MHz as fixed. The current value is a snapshot and can change with frequency scaling; it is not the processor's fixed specification.
• Writing to the file. Do not write to /proc/cpuinfo, try to create missing keys, or grant extra privileges to make a parser work. It's a read-only kernel view.
• Assuming a container sees everything. A container may expose a restricted CPU view, so compare the result with the limits applied to the workload.

For portable scripts, prefer a narrowly defined question. Count processor records when you need the view this file exposes. Use lscpu for topology. Use scheduler interfaces or the relevant runtime when you need CPUs available to a particular process. Those are different questions with different answers.