With the upcoming Linux 6.20~7.0 kernel cycle it looks like the time slice extension work could finally been merged, which has seen various attempts over the past decade. Time slice extension for the Linux kernel implemented using Restartable Sequences “RSEQ” allows user-space processes to request a temporary, opportunistic extension of their CPU time slice without being preempted.
Thomas Gleixner of Intel-owned Linutronix explained of the time slice extension work in last year’s patches as:
“Time slice extensions are an attempt to provide opportunistic priority ceiling without the overhead of an actual priority ceiling protocol, but also without the guarantees such a protocol provides.
The intent is to avoid situations where a user space thread is interrupted in a critical section and scheduled out, while holding a resource on which the preempting thread or other threads in the system might block on. That obviously prevents those threads from making progress in the worst case for at least a full time slice. Especially in the context of user space spinlocks, which are a patently bad idea to begin with, but that’s also true for other mechanisms.
This has been attempted to solve at least for a decade, but so far this went nowhere. The recent attempts, which started to integrate with the already existing RSEQ mechanism, have been at least going into the right direction. The full history is partially in the above mentioned mail thread and it’s ancestors, but also in various threads in the LKML archives, which require archaeological efforts to retrieve.”
After v6 patches over the past few months, this week the latest iteration of the Time Slice Extension patches were queued into tip/tip.git’s sched/core Git branch. With the patches finally working their way into a TIP branch, they will likely be submitted as part of the upcoming merge window with the other scheduler changes.
Now it’s just a matter whether Linus Torvalds decides to call the next kernel version Linux 6.20 or Linux 7.0.
