Linux kernel live patching and performance tuning: inside TurboKernel

Managed hosting | November 2026

Most hosting companies run whatever Linux kernel their distribution ships. That kernel is a careful compromise: it has to boot on a twenty-year-old laptop, a Raspberry Pi and a gaming PC, and it is often several years behind the current Linux release. Our servers don't do laptops or gaming. So we stopped running a kernel that was built for them.

TurboKernel is the Linux kernel we build, sign and run ourselves for every managed TurboStack server. It tracks the newest stable Linux release, it is compiled for the server CPUs we actually use, and it is tuned for one job: serving web applications, databases and APIs as fast as the hardware allows. TurboKernel runs Linux 7.3, the newest stable release, while the stock kernels on the same distributions are based on Linux 5.14 to 6.12.

Here are the five TurboKernel features we are most proud of, and what they mean for the applications running on top of them.

The short version: TurboKernel squeezes more performance out of the same hardware, keeps more of your data in fast memory under pressure, delivers pages faster over real-world networks, behaves identically on Debian and AlmaLinux, and can take critical security fixes without rebooting your server.

In this article

1. Linux kernel live patching: security fixes without a reboot
2. A Linux kernel compiled for modern server CPUs
3. BBR congestion control: faster delivery over real-world networks
4. Linux memory management that holds up under pressure
5. One Linux kernel for Debian and AlmaLinux
6. Bonus: what's new in Linux 7.2 and 7.3 for servers
7. What TurboKernel doesn't do
8. Frequently asked questions

1. Linux kernel live patching: security fixes without a reboot

Every server operator knows the dilemma. A serious kernel vulnerability is published. Fixing it means installing a new kernel, and a new kernel means a reboot. A reboot means downtime, a maintenance window, and a conversation with every customer on that machine. So in practice, much of the industry waits for the next convenient moment, and the server stays vulnerable in the meantime.

TurboKernel supports kernel live patching. A live patch is a small, signed module that replaces a vulnerable function inside the running kernel while the server keeps serving traffic. No reboot, no maintenance window, no dropped connections. Until a live patch is actually needed, the feature costs nothing: there is no performance penalty for having it ready.

Live patching sits on top of a fast lane we already run for every kernel release:

• Verified at the source. Every new stable Linux release is cryptographically checked against the signing keys of the Linux stable maintainers before we touch it.
• Built and boot-tested automatically. Our pipeline builds the new TurboKernel, boots it on Debian and AlmaLinux test machines and runs functional checks. A kernel that doesn't pass never reaches a customer server.
• Signed by us. Every kernel and every kernel module is signed with our own Hosted Power key, so what runs on your server is exactly what we built.

The result is a path from "Linux published a fix" to "the fix is on your server" that is measured in hours, not weeks. And for the fixes that qualify, that path no longer ends in a reboot.

2. A Linux kernel compiled for modern server CPUs

The x86-64 instruction set dates from 2003. Distribution kernels are still compiled for that original baseline, because they have to boot on anything. That means they ignore a decade of CPU improvements: wider vector instructions, faster bit manipulation and fused arithmetic that every modern server processor has had since 2013.

TurboKernel is compiled for the modern x86-64-v3 instruction level, so the compiler can use those instructions everywhere in the kernel. On top of that, we optimise the kernel as one whole program at link time, instead of as thousands of separate files. Functions that call each other millions of times per second get inlined, dead code disappears, and hot paths get shorter.

We also made deliberate server choices that a general-purpose kernel can't make:

• CPUs run at full speed by default. No waiting for the processor to clock up when a burst of requests arrives. Latency matters more to us than shaving a few watts off an idle server.
• A scheduler profile tuned for throughput. Desktop kernels prioritise smooth mouse movement. Ours prioritises getting database queries and PHP requests done, while keeping response times tight.
• Ready for big iron. TurboKernel scales to thousands of CPU cores, so the same kernel runs on a small VPS and on our largest multi-socket EPYC servers.

None of this requires a single change to your application. The same code simply runs on a faster foundation.

3. BBR congestion control: faster delivery over real-world networks

Your visitors are not on a perfect fibre connection. They are on hotel Wi-Fi, on 4G in a train, or on the other side of the world. Classic TCP congestion control reacts to every lost packet by slamming on the brakes, which is exactly the wrong reaction on a slightly lossy mobile link.

TurboKernel uses BBR congestion control by default, the model-based algorithm Google developed for its own services. Instead of panicking at packet loss, BBR measures the actual bandwidth and round-trip time of each connection and sends at the rate the path can really handle. Google reported double-digit throughput gains for YouTube in some countries after switching, and the biggest wins show up exactly where your customers are hardest to reach.

We pair it with fair-queue packet pacing, which smooths out bursts so packets don't pile up in routers along the way. That pacing is also what modern HTTP/3 and QUIC traffic wants, so our web servers get it out of the box.

And because speed without resilience is worthless, the TCP stack is hardened against floods of junk packets designed to make a server burn CPU on bookkeeping. Combined with TurboShield at the application layer, an attack has to work a lot harder before your shop notices anything.

4. Linux memory management that holds up under pressure

When a server runs low on memory, the kernel has to decide which data to keep close and which to push away. Get that wrong and you get the classic slowdown spiral: the server keeps evicting data it needs a moment later.

TurboKernel uses a newer, generation-aware page reclaim algorithm that tracks how recently and how often memory is really used. It keeps the active working set of your database and application in RAM and evicts what is truly cold. Published measurements on large fleets show around 40% less CPU spent on memory reclaim, which is CPU your application gets back exactly when the server is busiest.

Because we run the newest Linux, we also get every improvement to that algorithm the moment it lands. Linux 7.2 reworked how it reclaims and writes back memory, delivering up to 30% more throughput for MongoDB under memory pressure and far fewer cases of data being thrown out and read straight back in. Linux 7.3 teaches it to protect executable code: the PHP, Nginx and database binaries your server runs every millisecond stay in memory instead of being evicted and reloaded from disk.

That reclaim logic works hand in hand with TurboRAM, our compressed memory layer, which on one production host turns 32 GB of physical RAM into 41 GB of effective memory. Because the kernel picks genuinely cold pages to compress, TurboRAM holds parked data instead of data that gets pulled straight back.

And if memory really does run out, TurboKernel tracks memory pressure per service. Instead of letting the whole server crawl, the system can act on the one runaway process that causes the pressure, and leave your database alone.

5. One Linux kernel for Debian and AlmaLinux

We run both Debian and AlmaLinux, because different applications and control panels have different needs. With stock kernels, that means four different kernels across Debian 12, Debian 13, AlmaLinux 9 and AlmaLinux 10, ranging from Linux 5.14 to 6.12, each with its own bugs, quirks and patch schedule.

TurboKernel is the same kernel on all four. Same Linux version, same tuning, same security fixes on the same day. For you, that means:

• Predictable performance. A benchmark on Debian tells you what to expect on AlmaLinux. Moving between distributions doesn't mean relearning how the server behaves.
• Modern Linux on stable distributions. You keep the stability and long support of Debian or AlmaLinux, with a kernel that is years ahead of what they ship.
• Faster fixes for everyone. One kernel means one pipeline, so a fix reaches every server type at once instead of four separate queues.

It also means our engineers know one kernel inside out, instead of four kernels a little bit. When something behaves strangely, the answer is the same everywhere.

Bonus: what's new in Linux 7.2 and 7.3 for web and database servers

Because TurboKernel follows the newest stable Linux, our servers get improvements that distribution kernels will only see years from now, if ever. A selection of what Linux 7.2 and 7.3 add for web and database servers:

Scheduler: keeping work close to its data

• Cache-aware scheduling (7.2). Threads that share data are kept on cores that share the same CPU cache. Modern EPYC processors are built from multiple chiplets, each with its own cache, so this means fewer slow trips to main memory for busy database and application workloads.
• Flattened group scheduling (7.3). On a TurboStack server, every service, every PHP pool and every database runs in its own control group. Linux 7.3 schedules those groups from a single queue instead of a tree of queues, cutting overhead and latency on exactly the kind of multi-service server we run.
• Lower scheduling latency (7.3) for short-running tasks such as web requests, and smarter use of fully idle cores.

Memory: faster under pressure

• Over 60% less lock waiting during memory reclaim (7.3), so a busy server spends less time contending with itself.
• Compressed memory up to 1.8× faster to release (7.3), directly benefiting TurboRAM.
• Leaner, faster swap (7.2 and 7.3). Less memory spent on swap bookkeeping and batched swap I/O, so the safety net costs less when it is needed.
• More large memory pages (7.2). The kernel can now group more application and file memory into large pages, reducing address-translation overhead for databases and caches.

Storage: more IOPS from the same NVMe

• Up to 14% more IOPS for small direct I/O on ext4 (7.3), the access pattern databases rely on: from 1.92 to 2.19 million IOPS in the developers' benchmark.
• Parallel direct writes on ext4 (7.3). More database writes proceed at the same time instead of queueing behind a lock.
• About 5% more random-read IOPS on ext4 and XFS (7.2) on NVMe, plus faster ext4 journal commits.

Security: tighter sandboxes

• Signed eBPF programs (7.3). The kernel verifies eBPF loaders before running them. Full eBPF support is also what lets TurboStack watch for intrusions and suspicious behaviour in real time on every server, with almost no overhead.
• Stronger sandboxing (7.2 and 7.3). Finer-grained network rules for sandboxed services, protection against services being tricked into opening devices or pipes instead of files, and kernel threads isolated from the rest of the system.

None of this requires a change on your side. It simply arrives with the next TurboKernel update.

What TurboKernel doesn't do

We like to be clear about the limits.

It doesn't fix slow code. A missing database index or an N+1 query will still be slow, just slightly less so. A faster kernel is a foundation, not a replacement for a performance review.

It needs a modern CPU. TurboKernel is compiled for processors from roughly 2013 onwards. Our own hardware has qualified for years; for the rare older machine we keep the standard kernel rather than risk it.

Not every fix can be live-patched. Live patching covers most critical security fixes, but some changes still need a new kernel and a reboot. When they do, we plan them like any other maintenance, with notice.

Curious what TurboKernel would do for your application?

Ask us to review your current environment. We'll tell you what changes on day one and where the real bottlenecks are.

Request an infrastructure audit

Frequently asked questions

What is Linux kernel live patching?

Live patching replaces a vulnerable function inside the running Linux kernel with a fixed version, using a small signed kernel module. The server keeps running and serving traffic while the fix is applied, so there is no reboot and no downtime.

Does live patching mean a server never needs a reboot?

No. Live patching covers most critical security fixes, but larger kernel updates still need a reboot. The difference is that we can schedule those calmly, with notice, instead of rushing a reboot because a vulnerability is open.

Which Linux kernel version do your servers run?

TurboKernel follows the newest stable Linux release, currently Linux 7.3, on Debian 12 and higher and AlmaLinux 9 and higher. Stock kernels on the same distributions are based on Linux 5.14 to 6.12.

Is a custom Linux kernel safe for production?

That depends entirely on how it is built. Every TurboKernel starts from verified upstream Linux sources, is built and boot-tested automatically on Debian and AlmaLinux, and is signed with our own key before it reaches a single customer server.

Do I need to change my application to benefit?

No. TurboKernel sits underneath your application. PHP, Node.js, Python, databases and caches run unchanged, just on a faster and better-protected foundation.

Included, not an upsell

TurboKernel runs on every managed TurboStack server on Debian 12 and 13 and higher and AlmaLinux 9 and 10 and higher. We don't sell it as an add-on and you don't have to ask for it. The engineering work is in building, testing, signing and operating it, so that you never have to think about the kernel at all.