Linus Torvald's release announcement didn't announce any major changes for Linux 6.8. Anyone waiting for new file systems, world-changing features and tons of new supported hardware will indeed be disappointed. Only the new graphics driver for Intel Xe stands out as a novelty for Torvalds in this sense. Nevertheless, Linux 6.8 has a lot of interesting things in store, even if most of it is hidden beneath the surface.
Advertisement
In addition, Linux 6.8.1 has already been released. The update to 6.8.1 is strongly recommended for all Linux 6.8 users. It contains important security and bug fixes.
First driver in Rust
Up until now, there was relatively little to do with Rust in the stable Linux kernel. At the end of 2022, Rust officially celebrated its debut with kernel 6.1. However, this has not yet been used for new modules or drivers. With Linux 6.8 comes the first usable, functional driver programmed in Rust. This driver supports Asix Electronics AX88796B Fast Ethernet controllers. The hardware is mainly used in the embedded area in industrial applications.
Linux already has a driver for AX88796B written in C. The Rust variant reimplements the function of its C counterpart one-to-one. By default, the C variant is preselected in the Linux kernel. If you want the Rust version, you can use the switch when configuring the kernel before the build AX88796B_RUST_PHY
to select.
It's a clever move to recreate an existing and working driver in Rust. Since the same driver is available in C and in Rust, Rust can be compared directly with C in practical tests and tested sensibly. This would not be possible with a new driver for previously unsupported hardware.
At the same time, the development team creates the necessary foundation for physical network drivers in the form of the necessary abstraction layers. Future network drivers can generally be programmed either in C or Rust.
Division of labor
The focus of the Linux kernel remains on scheduling, i.e. distributing computing time among the individual competing processes. After Linux 6.6 radically replaced the standard scheduler, Linux 6.8 goes further in this area.
The new scheduler EEVDF (Earliest Eligible Virtual Deadline First) introduced with Linux 6.6 is being tuned. By introducing a fastpath mechanism, the task involved can be selected more efficiently. The whole thing with a constant magnitude of O(1). Initial tests show that the “O(1) Fastpath” actually makes the task selection and thus the scheduler as such work more efficiently.
In the real-time area, the new kernel optimizes the deadline scheduler. This is based on the quite simple concept of “POSIX Realtime Scheduling Classes”. The real-time tasks indicate how much computing time they require and by when they must have completed their work. Depending on how urgently such tasks need to be completed, they are prioritized and given CPU time earlier. If such a system were to run without any further precautions, it could happen that the real-time tasks starve the “normal” ones. Anything that doesn't have the “real-time stamp” would have to be put aside. In this case, a system that is busy would quickly be perceived as “hanging”. While real-time tasks would be processed, all control options such as login, starting administrative tasks, etc. could be slowed down in the long term. It would no longer be possible to influence the system. A cold start would be the only solution.
Terminsache
To prevent this, the kernel reserves a fixed proportion of CPU time for these low-priority tasks. By default this is five percent; 95 percent remains for real-time processing. This means that a system always has enough resources to administer, regardless of the workload. The solution is called “Realtime Throttling”.
However, this solution is anything but optimal. This reserved five percent remains reserved even if there are no low-priority tasks to be carried out. The system is therefore constantly five percent “idle”, even if the real-time processes could use this little bit more performance.
The new solution presents itself as a “deadline server”. Instead of reserving fixed CPU time, the scheduler puts the low-priority tasks into a separate deadline class – the “deadline server”. It has a higher priority than the POSIX real-time classes in which the real-time processes take place. This means that the tasks with a “low” priority are given “highest” priority in the real-time round and are always given priority over the real-time tasks.
The highlight only becomes apparent at second glance. The “deadline server” declares a CPU requirement of five percent. This means that it is initially capped so that the real-time tasks receive at least 95 percent of the CPU time, as originally. If there are no tasks waiting to be executed in the “deadline server”, the scheduler recognizes this and quickly distributes the requested but unused five percent CPU time to the real-time tasks. On the one hand, this ensures that the “low” priority but administratively important tasks always receive sufficient CPU time. On the other hand, these reserved CPU resources do not simply sit idle when they are not needed.