Cache and TLB behavior can make a Linux system feel fast, slow, smooth, or strangely stalled.
These effects are often invisible at first because the CPU may not be busy doing useful work.
It may be waiting on memory.
Performance problems are not always caused by lack of CPU power.
Sometimes the processor is fast, but the memory path cannot feed it efficiently.
High-Level Diagnostic Idea
Program runs
↓
Memory access pattern matters
↓
TLB hit or miss
↓
Cache hit or miss
↓
RAM access or stall
↓
Visible performance behavior
What “Pressure” Means
Cache or TLB pressure means a workload is stressing the fast lookup structures inside the CPU.
The TLB cannot hold enough address translations.
The cache cannot hold enough useful data.
The CPU must repeatedly fetch from slower levels.
A system can have plenty of free memory and still suffer from poor cache or TLB behavior.
Signs You Might See
Programs feel slower than expected.
CPU usage is moderate, but latency is high.
Performance drops sharply with larger data sets.
Adding threads does not improve throughput.
Disk is not busy, but the program still stalls.
Workload is sensitive to data size or access pattern.
First-Level Tools
top
top
Use top to get a quick sense of CPU usage, load average, memory use, and which processes are active.
vmstat
vmstat 1
Use vmstat to watch runnable processes, memory activity, swap activity, I/O wait, and CPU states over time.
free
free -h
Use free to understand broad memory availability, cache use, and swap context.
These tools do not directly prove cache or TLB pressure, but they help rule out simpler explanations.
Process-Level Clues
Process list
ps -eo pid,ppid,stat,comm,%cpu,%mem --sort=-%cpu | head
Page faults for a process
ps -o min_flt,maj_flt,cmd -p <PID>
Minor faults are often normal. Major faults are more concerning because they may involve disk or backing-store access.
Memory map
cat /proc/<PID>/maps
This shows the process address space: text, heap, stack, libraries, and mapped regions.
Using perf
perf can expose hardware-level behavior such as cycles, instructions, cache references, cache misses, and TLB misses.
Basic run
perf stat <command>
Cache-focused run
perf stat -e cycles,instructions,cache-references,cache-misses <command>
TLB-focused run
perf stat -e dTLB-loads,dTLB-load-misses <command>
List supported events
perf list
Available perf events depend on the CPU, kernel, permissions, and system configuration.
How to Think About Results
High cache misses
↓
CPU often waits for lower cache or RAM
High TLB misses
↓
CPU often walks page tables
High major faults
↓
Memory may require disk or backing-store access
High cycles but low useful work
↓
CPU time may be lost to stalls
Common Patterns
Small data set is fast; large data set is slow
The small data set may fit in cache. The large data set may exceed cache capacity or TLB reach.
Sequential access is fast; random access is slow
Sequential access benefits from spatial locality and prefetching.
Random access defeats locality and causes more cache and TLB misses.
More threads do not help
If the workload is memory-bound, adding more CPU workers may increase contention without improving throughput.
VM or container behaves differently than bare metal
Virtualization and container limits can change memory locality, scheduling behavior, and translation overhead.
Practical Investigation Path
1. top / vmstat
↓
2. identify process
↓
3. inspect memory map
↓
4. check page faults
↓
5. run perf stat
↓
6. compare small vs large workload
↓
7. compare sequential vs random access
Possible Improvements
The right fix depends on the workload, but common improvements include:
Improve data locality.
Use more compact data structures.
Avoid large random access patterns.
Batch related work together.
Reduce unnecessary process or thread churn.
Consider huge pages for suitable large-memory workloads.
Profile before guessing.
Do not assume “more CPU” fixes memory-path problems.
A faster processor can still stall while waiting for memory.
Connection Back to the Journey
The hidden life of a Linux command does not end when the program starts running.
Once running, its performance depends on how well it interacts with memory.