Time Slice Extension: A Decade-Long Journey Toward the Linux Scheduler

Time Slices: Fixed Quota or Fair Referee?

Early Linux schedulers gave each process a fixed time slice; when exhausted, the process was forcibly switched out. But since CFS (Completely Fair Scheduler) arrived in 2007, preemption is no longer driven by a mechanical timer. Instead, the scheduler acts like a shrewd referee, using each task's virtual runtime (vruntime) to decide who runs next — the smaller the vruntime, the more CPU time a task "owes," and the higher its priority.

Because CFS is so committed to overall fairness, any attempt to secretly extend one task's time slice touches the nervous system of the whole scheduling design. That is why the Time Slice Extension patch troubled the Linux community for a full decade.

The Embarrassment of User-Space Locks

Picture a relay race where the baton carries a million-dollar lottery ticket. You only need to run 10 meters — but at meter 5, the referee blows the whistle: "Time's up! Swap!" You stop, the baton is confiscated, and the next runner spins in place doing nothing.

This absurd scenario plays out daily in high-concurrency Linux systems, where the baton is a user-space spinlock:

• Thread A holds the lock inside an extremely short critical section — typically hundreds of nanoseconds to a few microseconds, too short to justify entering the kernel or sleeping.
• Thread B wakes, finds the lock held, and spins.
• If the scheduler preempts A exactly because its time slice expired, B burns CPU spinning while A — the one doing real work — sits in the run queue. Throughput collapses and tail latency spikes.

This is not a theoretical edge case. User-space locks are everywhere:

• glibc's memory allocator
• High-performance allocators like jemalloc/tcmalloc
• User-space concurrency structures in database engines
• High-frequency trading systems
• Game servers

All share the same trait: tiny, deterministic critical sections where unnecessary preemption destroys overall performance.

An "Opportunistic Priority Ceiling"

Thomas Gleixner — the renowned maintainer of the kernel's time subsystem, from Linutronix (an Intel company) — offered an elegant definition in the patch description:

> Time Slice Extension is an "opportunistic priority ceiling."

Two things matter here:

1. It is not traditional priority inheritance. Classic priority inheritance dynamically adjusts scheduler entity weights, modifies vruntime, reorders the red-black tree, or changes nice values — expensive operations that can break CFS's fairness model. Time slice extension touches none of that; it merely, under specific conditions, nudges the current time slice slightly longer so a thread can finish a short critical section. 2. It is opportunistic. Extension only happens when it happens to be possible. No guarantees, no real-time promises. Under heavy load or when a task has severely overspent its vruntime, the scheduler will still preempt without mercy.

This is the essence of Linux philosophy: a best-effort optimization, not a hard real-time guarantee.

Why Every Previous Attempt Failed

The need is not new — ideas surfaced on LKML around 2010, but each round died in the same pits:

1. How can user space safely tell the kernel "I'm in a critical region"? A syscall like please_dont_preempt_me() costs too much — one syscall can wipe out the entire benefit of a microsecond critical section, defeating the "no-syscall fast path." Fully implicit signaling means the kernel has no idea what you're doing; user space can lie freely and safety collapses. 2. How to prevent abuse? If any process can declare "don't preempt me, I'm important," malicious or badly written programs can starve everyone else, rendering the scheduler meaningless. 3. Inherent conflict with CFS fairness. CFS relies on precise vruntime accounting. Even a few extra microseconds for one process can accumulate into real unfairness over long timescales.

RSEQ: The Turning Point

The real breakthrough came from a seemingly unrelated feature: RSEQ (Restartable Sequences).

RSEQ lets user space register a restartable code region. If execution there is interrupted by preemption, CPU migration, or a signal, the kernel automatically rolls the program counter back to the start for re-execution. It is already widely adopted — glibc's fast getcpu(), jemalloc, PostgreSQL, Redis, and countless lock-free data structures.

The key insight: once a thread registers an RSEQ critical section, the kernel already "partially knows" it is executing a special, integrity-sensitive code segment. This reframes the problem from "user space freely demanding favors" to "slightly relaxing preemption inside a kernel-approved, verifiable region."

Time slice extension rides on RSEQ: extension can only trigger while an RSEQ critical section is active, with an upper bound, condition checks, and full opportunism. This solves both the security/abuse problem and nearly preserves CFS's fairness model — a perfectly Linux-style compromise.

From Repeated Failure to tip/sched/core

Over more than ten years, the patch went through countless versions and rejections. In 2025–2026, a new version pushed jointly by Mathieu Desnoyers (RSEQ's original author) and Thomas Gleixner iterated to v6 — and has been merged into tip.git's sched/core branch.

tip.git is the scheduler development repository maintained by Peter Zijlstra; sched/core is the staging entrance for all scheduler changes. Getting in means the design direction is endorsed by the subsystem maintainer, the code meets long-term maintainability standards, and the risk is acceptable. It is one foot in mainline — likely submitted to Linus Torvalds in the next merge window (perhaps 6.21 or 7.0).

What It Means for Users and Operators

Time slice extension won't change the world overnight like eBPF, but it will quietly improve:

• Tail latency (p99, p99.9) of highly concurrent applications
• Throughput stability under user-space lock contention
• "Inexplicable" jitter under multi-core load

If you run Redis, PostgreSQL, game servers, microservices, or anything depending on high-performance user-space concurrency, this patch will silently save you CPU cycles — and electricity — after some future kernel upgrade.

Epilogue: Linux's Long-Termism

The story of time slice extension is a microcosm of Linux kernel development philosophy:

• Problems are often raised more than a decade before they are solved
• Solutions endure countless failures and rounds of polishing
• Short-term performance is never traded away for long-term maintainability and fairness
• Final victories often come from cleverly reusing existing mechanisms — here, RSEQ

Once merged, it will join CFS and RSEQ as a foundation of the Linux kernel that is almost impossible to remove.

------

References

1. Man Tan Jun. Why Could One "Time Slice" Trouble Linux for Ten Years? WeChat public account "Yunwei Man Tan," 2026-01-25. 2. Thomas Gleixner. [PATCH v6 0/6] sched: Time slice extension mechanism. LKML, 2025. 3. Mathieu Desnoyers. Restartable Sequences (RSEQ) kernel ABI. Linux Kernel Documentation, 2019-2025. 4. Peter Zijlstra. CFS Scheduler Documentation. Linux Kernel source tree: Documentation/scheduler/sched-cfs.txt. 5. Ingo Molnar. Completely Fair Scheduler (CFS) introduction. LKML announcement, 2007.