Kernel Memory Calculator
Estimate kernel memory footprint including slab allocations and kernel structures.
About Kernel Memory Calculator
Kernel memory — largely invisible to normal process-level monitoring — includes Slab (cache for frequently allocated kernel objects like inodes, dentries and network buffers), KernelStack (per-thread kernel-mode stacks), PageTables (memory mapping structures, which grow with the number and size of process address spaces) and VmallocUsed (virtually contiguous kernel allocations, notably used by kernel modules and some drivers). Summing these from /proc/meminfo approximates total kernel overhead, useful for explaining a RAM gap between 'sum of process RSS' and actual total used memory.
Formula
Total kernel memory
kernel_memory = Slab + KernelStack + PageTables + VmallocUsed
- S
- Slab
- K_stack
- KernelStack
- P_tables
- PageTables
- V_used
- VmallocUsed
Worked example
With the default values below, Kernel Memory Calculator returns Total Kernel Memory (MB) of 736.00. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Slab (MB, from /proc/meminfo)minimum 0
- 512
- KernelStack (MB)minimum 0
- 32
- PageTables (MB)minimum 0
- 128
- VmallocUsed (MB)minimum 0
- 64
- MemTotal (MB)minimum 1
- 16,384
Results
- Total Kernel Memory (MB)
- 736.00
- Kernel Memory as % of RAM
- 4.49%
- Slab Share of Kernel Memory
- 69.57%
- Assessment
- Elevated — worth checking `slabtop` for which slab caches are largest, especially on high-connection-count servers.
Step by step
- 1Values used
- 2Total kernel memory
- 3Total Kernel Memory (MB)= 736.00
- 4Kernel Memory as % of RAM= 4.49
- 5Slab Share of Kernel Memory= 69.57
- 6Assessment= Elevated — worth checking `slabtop` for which slab caches are largest, especially on high-connection-count servers.
Assumptions and limits
- The result is derived only from the 5 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why is Slab memory growing on my server over time?
Slab caches grow as the kernel allocates more of the objects they hold — commonly dentry and inode caches on servers touching many files, or networking buffers on servers with many concurrent connections. `slabtop` shows a live, sorted breakdown by cache name and size to identify which specific cache is growing.
Does the kernel ever release Slab memory back to the system?
Yes, under memory pressure most reclaimable slab caches (marked SReclaimable in /proc/meminfo, as opposed to SUnreclaim) are freed automatically, similar to page cache. Some caches remain unreclaimable while actively in use, which is why sustained SUnreclaim growth is a more meaningful signal to investigate than SReclaimable growth.
Why does PageTables memory grow with more processes?
Each process's virtual address space requires page table entries to map virtual to physical addresses, and processes with many memory mappings (large heaps, many shared libraries, or many threads with separate stacks) need proportionally more page table memory — this is one reason very high process/thread counts carry real, if often overlooked, kernel memory cost.