Your production server’s humming along — until it isn’t. And now, one obscure kernel knob you might’ve twiddled for better memory performance? Gone.
Linux just decided to remove read-only transparent huge pages from the page cache. Not a big flashy change. But it stings if you’re the type who pores over Kconfig options at 2 a.m.
Here’s the thing. Back in 2019, dev Song Liu added support for these read-only THP in the page cache. Promised writable versions “in the next few release cycles.” Six years on? That line’s still there. But writables? Never happened. Instead — poof — read-only’s out.
What the Hell Were Read-Only THP Supposed to Do?
Transparent huge pages. THP. Kernel’s way of glomming 2MB pages together instead of puny 4KB ones. Faster lookups. Less TLB thrashing. Sounds great for page cache — that giant pool of file data Linux keeps in RAM.
But read-only only. Why? Page cache can get dirtied — writes happen. So Song figured, keep ‘em read-only for clean, shared pages. Like mmap’d executables. Efficient, right?
When the kernel gained support for the creation of read-only transparent huge pages for the page cache in 2019, the developer of that feature, Song Liu, added a Kconfig file entry promising that support for writable huge pages would arrive “in the next few release cycles”.
That’s the hook. Straight from the patch notes. Optimism on steroids.
Reality? Memory subsystem evolved. Multi-Gen LRU. Smarter reclaim. THP collapse got better for anon pages. Page cache? Didn’t need this half-baked crutch.
A single line in Kconfig. But it screamed confidence.
Why Ditch It Now — And Who Cares?
Kernel devs don’t flip lightly. This lands in v6.15, via patches from Yuanchu Xie. Reason? Performance regressions. Benchmarks showed read-only THP in page cache slowing things down. Under the new memcg hierarchies, even worse.
It’s like building a Ferrari with bicycle tires. Cute idea. Crashes in practice.
Real people hit? Sysadmins on huge file servers. Think web caches, databases slurping logs. You enabled CONFIG_READ_ONLY_THP_FOR_FS? Kiss it goodbye. But — and this is key — most distros never flipped it on. Fedora? No. Ubuntu? Nah. Usage near zero.
So, impact? Meh for 99%. But it burns.
Is Your Kernel About to Explode?
No.
This is a config option removal. If you weren’t compiling custom kernels with it — and why would you? — nothing breaks. Runtime? Kernel ignores it silently now anyway.
But dig deeper. It’s a symptom. Kernel’s shedding skin. Early THP experiments — anon collapse, madvise tweaks — matured. Page cache THP? Stunted child, never grew up.
My hot take, one you won’t find in LWN: This echoes the io_uring saga. Hyped as filesystem revolution. Years later, still wrestling security holes and complexity. Kernel devs promise the moon, deliver… incrementally. Or not at all.
Bold prediction: Writable page cache THP? Deader than disco. Multi-Gen LRU’s got the future locked.
Servers chug on. But trust those Kconfig teases less.
The Developer Drama — Six Years of Crickets
Song Liu’s patch. v5.3 timeframe. Enthusiasm palpable. “Soon writables!”
Cut to 2025. Memory folks like Yuanchu say, nope. Data shows regressions on file servers. THP splitting under write pressure — ironic for read-only — tanks perf.
Patch series drops it clean. No fanfare. Just Kconfig prune, code rm. Linus nods.
Dry humor time: It’s like proposing marriage, ghosting for six years, then canceling the wedding via text. Kernel style.
Why Does This Matter for Server Admins?
You’re not recompiling kernels daily. But this flags bigger shifts. Linux memory management’s peaking — DAMON, MGLRU, now THP refinements. Page cache’s getting leaner, meaner.
Tradeoff? Fewer knobs. Less tweakability. Good for stability. Bad if you’re a tuning freak.
Historical parallel — remember vmscan tweaks circa 2010? Everyone hacked swappiness. Now? Autotuned. Progress.
But it irks. Corpse of a feature, promised more, left to rot.
One para wonder: Distros will update. Your reboot? smoothly.
The Bigger Picture: Kernel’s Pruning Spree
This isn’t isolated. Khugepaged tweaks. Anon THP always-on debates. Linux is battle-hardened — 30+ years. Features get axed when they don’t scale.
Critique the spin — or lack. No big announcement. Just merges. Devs move fast, break… options.
For users? Benchmark your workloads. If page cache THP helped (it didn’t for most), hunt alternatives. PSI metrics. Earlyoom. Smarter tools.
And yeah, it’s open source. Fork it back if desperate. Good luck.
🧬 Related Insights
- Read more: Data Centers Ditch ACI for NX-OS VXLAN EVPN in 2026
- Read more: Rabarber v6: The Rails Auth Gem That Finally Ditches the Dead Weight
Frequently Asked Questions
Will removing read-only THP break my Linux server?
Nope. Unless you custom-built with it enabled — rare. Distros ignored it.
What replaced read-only transparent huge pages?
Nothing direct. Multi-Gen LRU and refined anon THP handle the load better.
Why did Linux promise writable THP but remove read-only instead?
Perf regressions. Memory subsystem outgrew the idea. Promises? Kernel’s eternal optimism.
