Linux 7.4 reportedly fixes how the kernel reports TLB size on AMD Zen 5 and newer CPUs. That headline sounds like a performance story, but the evidence points to a reporting correction. This guide shows how to read the value your kernel reports, how to compare it before and after an upgrade, and where the public details run out.
One caveat up front. The Phoronix report is titled "Linux 7.4 Fixes AMD CPU TLB Size Reporting For Zen 5 & Newer". It follows a September story about a patch for under-reported Zen 5 TLB sizes.
The headline alone does not give the commit hash, the affected field, the old and new values, or any stable backports. The sections below flag those gaps instead of guessing.
What is a TLB, and why does the kernel report its size?
A translation lookaside buffer (TLB) is a small cache inside the CPU. It stores recent translations from virtual addresses, which programs use, to physical addresses in RAM. Without it, nearly every memory access would first need a walk through the page tables.
The kernel reads TLB geometry from CPU identification data at boot. On x86 it generally does this through the CPUID instruction, then exposes a summary to userspace. That summary is informational: tools and admins read it, but a number printed in a file is not the same as hardware capacity.
The Phoronix headline does not say whether the kernel also uses the value for any internal decision. Treat that as unconfirmed until you read the commit message.
How do I see the reported TLB size on my Zen 5 system?
All commands below are untested. They are standard tools, but no output has been captured, so expect differences between distributions and kernel builds. You need only a shell on the machine.
Most major distributions package the optional cpuid utility under that name. Install it with your package manager if you want raw leaf data.
## 1. Kernel summary (untested)
grep -m1 -i 'tlb' /proc/cpuinfo
grep -m1 'model name' /proc/cpuinfo
uname -r
## 2. lscpu (untested)
lscpu | grep -i -E 'model name|tlb'
lscpu -C
## 3. Optional raw CPUID dump (untested, may need root)
cpuid -1 | grep -i -A12 'L1 TLB\|L2 TLB\|TLB'
On x86 builds that print it, /proc/cpuinfo has a line labeled "TLB size", counted in 4K pages. That is general kernel behavior, not something confirmed from the Zen 5 patch. Whether the fix touches that exact line is an inference from the headline, so check it on your own machine. We cover related ground in speed up linux kernel compile time: 7 practical fixes explained.
lscpu focuses on topology and caches, and it may print nothing for TLBs. An empty grep result is expected, not an error.
The cpuid tool decodes the raw AMD leaves, which is the closest userspace view of what firmware and silicon advertise. If the kernel summary and the cpuid output disagree, compare the two.
What did the Zen 5 fix actually change?
The confirmed part is narrow. Per the Phoronix headline, the Linux 7.4 work corrects TLB size reporting for Zen 5 and newer AMD CPUs. The September patch targeted under-reported sizes, which means the kernel showed a smaller figure than the CPU has.
Everything else is unconfirmed: the CPUID leaf or kernel variable involved, the before and after numbers, and whether other fields changed. Look up the commit before quoting any figure.
A reasonable starting point is a log search in a kernel tree. The path below assumes the change sits in AMD CPU setup code. That is a guess, so verify it.
## Untested; path is an assumption
git log --oneline v7.3..v7.4 -- arch/x86/kernel/cpu/amd.c
The Linux 7.4 merge notes, on the kernel mailing list or in the x86 pull request, will name the exact commit.
Does the under-reported value affect performance or only the displayed information?
The TLB is physical silicon. A kernel patch to reporting cannot resize it, and an under-reported number does not shrink it. That follows from how hardware works, and it is why this article treats the fix as a reporting correction by default.
The open question is whether Linux consumes the reported value for tuning. The Phoronix headline does not claim a performance effect. Without the commit message, a performance claim in either direction would be speculation.
| Claim | Category | Status | |---|---|---| | Linux 7.4 includes a Zen 5 and newer TLB size reporting fix | Kernel version | Stated in the Phoronix headline | | The old value was lower than the CPU's real TLB size | Reporting | Stated in the September patch coverage; exact numbers unconfirmed | | The physical TLB capacity changes with the patch | Hardware | No. Inference: software cannot resize silicon | | Real-world speed changes after the fix | Performance | Not established; no source claims it | | The fix is backported to stable kernels | Distribution | Not confirmed; check stable changelogs |
Check every unconfirmed row against the kernel commit and the 7.4 merge notes before you act on it. See close_range syscall explained: what sync closing changes: the details for additional background.
How do I know whether my kernel has the fix, and do I need Linux 7.4 or a backport?
The fix is merged for Linux 7.4, so a mainline 7.4 or later kernel should carry it. Whether any 7.3 or older stable branch received it is not confirmed. Distribution kernels often carry backports under a version number that looks old, so uname -r alone can mislead you.
The reliable method is a before and after comparison. Save the output now, update, reboot, and diff. All commands are untested.
Also read: also worth reading: beginner-friendly terminal editor: ttt vs micro vs edit
## Before the upgrade (untested)
{ uname -r; grep -m1 'model name' /proc/cpuinfo; grep -m1 -i 'tlb' /proc/cpuinfo; } > ~/tlb-before.txt
## Update the kernel with your package manager, then reboot.
## After the upgrade (untested)
{ uname -r; grep -m1 'model name' /proc/cpuinfo; grep -m1 -i 'tlb' /proc/cpuinfo; } > ~/tlb-after.txt
diff ~/tlb-before.txt ~/tlb-after.txt
A changed TLB line alongside a new kernel version suggests the fix is active. An identical line means one of three things:
- The old kernel already had a backport.
- The new kernel does not have the fix.
- The field you printed is not the one that changed.
To tell which, search your package changelog for TLB, for example with rpm -q --changelog kernel or apt changelog on the kernel package (both untested). If you boot a different kernel from GRUB for the comparison, you can recover by selecting the previous entry at the next boot.
Most people need no action beyond a normal kernel update. Do not hold back a security update or swap kernels just to chase this number.
Does a low TLB number mean my Zen 5 CPU was running slower?
No, and this is the most likely misreading of the news. "Under-reported" describes what the kernel printed, not what the CPU did. The TLB kept working at its real size the entire time.
The same logic applies to the fix. A bigger number after upgrading to Linux 7.4 does not mean your workloads got faster. To find out whether anything performance-related changed, benchmark your own workload on both kernels, and read the commit message for any mention of in-kernel use of the value.
Until the commit text says otherwise, the safest reading is that Linux 7.4 makes the information more accurate. That helps anyone who audits hardware inventories, compares CPU data across fleets, or files bug reports with /proc/cpuinfo output attached.
