Linux 5.5 "Kleptomaniac Octopus" Is Released
Linux 5.5 has a reworked fair scheduler, better live kernel patching, parallel microcode updates, NVMe temperature monitoring using hwmon, support for overclocking and 8K resolutions on AMD Navi graphics cards, support for LEDs on Logitech keyboards and several other improvements.
The announcement[edit]
The Linux 5.5 Makefile.
"So this last week was pretty quiet, and while we had a late network update with some (mainly iwl wireless) network driver and netfilter module loading fixes, David didn't think that warranted another -rc. And outside of that, it's really been very quiet indeed - there's a panfrost driver update too, but again it didn't really seem to make sense to delay the final release by another week.
Outside of those, it's all really tiny, even if some of those tiny changes touched some core files.
So despite the slight worry that the holidays might have affected the schedule, 5.5 ended up with the regular rc cadence and is out now.
That means that the merge window for 5.6 will open tomorrow, and I already have a couple of pull requests pending. The timing for this next merge window isn't optimal for me - I have some travel and other things going on during the same two weeks, but hopefully it won't be all that noticeable. But there might be random timezones, odd hours, and random delays because of that. I try to avoid scheduling things during the merge window, but hey, it doesn't always work out, and I'd have to delay things by two weeks to avoid the conflicts, which just doesn't seem worth it.
Particularly since it's not necessarily going to be a problem to begin with. We'll see.
Anyway. Go out and test 5.5, and start sending me those pull requests for all the new development that is ready,"
January 26th, 2020
Better "Completely Fair" Scheduler[edit]
It turns out that the Linux kernel's "Completely Fair" process scheduler wasn't all that fair. Linus merged a large scheduling patch-set by Vincent Guittot which tries to make its load-balancing actually "completely fair". The comments for that rather large patch-set which made it into Linux 5.5 are:
"The biggest changes in this cycle were:
- Make kcpustat vtime aware (Frederic Weisbecker)
- Rework the CFS load_balance() logic (Vincent Guittot)
- Misc cleanups, smaller enhancements, fixes.
The load-balancing rework is the most intrusive change: it replaces the old heuristics that have become less meaningful after the introduction of the PELT metrics, with a grounds-up load-balancing algorithm.
As such it's not really an iterative series, but replaces the old load-balancing logic with the new one. We hope there are no performance regressions left - but statistically it's highly probable that there *is* going to be some workload that is hurting from these changes. If so then we'd prefer to have a look at that workload and fix its scheduling, instead of reverting the changes"
More Responsive Wi-Fi[edit]
Linux 5.5 has a new Airtime-based Queue Limit in the CoDel (controlled delay) scheduling algorithm which should make wireless drivers using hardware (or firmware) offloading more responsive. Big hardware buffers are fine if you are transferring a large file and that is all you are doing. They become an issue if you are trying to do something latency-critical since the hardware, not the kernel, decides what order packets are sent. Do note that Codel (CONFIG_NET_SCH_CODEL) is not the default network scheduler on any major GNU/Linux distribution, you will have to configure your network interface(s) to use it if you want CoDel network scheduling.
Improved Live Kernel Patching[edit]
Linux 5.5 will have a brand new system state API written by SUSE developer Petr Mladek. The kernel's existing live patching functionality can now track the system state when patches are applied. This is especially useful if a newly applied patch does not work out. Applying a patch to a current kernel will in most cases make it impossible to revert back to the original kernel code or previous versions of a patch.
The new livepatch/system-state.rst kernel documentation describes the new new system state API as:
"Some users are really reluctant to reboot a system. This brings the need to provide more livepatches and maintain some compatibility between them.
Maintaining more livepatches is much easier with cumulative livepatches. Each new livepatch completely replaces any older one. It can keep, add, and even remove fixes. And it is typically safe to replace any version of the livepatch with any other one thanks to the atomic replace feature.
The problems might come with shadow variables and callbacks. They might change the system behavior or state so that it is no longer safe to go back and use an older livepatch or the original kernel code. Also any new livepatch must be able to detect what changes have already been done by the already installed livepatches.
This is where the livepatch system state tracking gets useful. It allows to:
- store data needed to manipulate and restore the system state
- define compatibility between livepatches using a change id and version
"
This is good for Cloud-providers who are typically very "reluctant to reboot a system".
Parallel CPU Microcode Updates Are Back[edit]
On the topic of cloud providers: They will no longer have to wait the entirety of several milliseconds when they apply CPU microcode updates to mega-core systems. The Linux kernel used to apply CPU microcode in parallel. This feature removed due to the huge amount of bugs and flaws in Intel CPUs. That's a problem for Cloud providers and others with systems with a huge amount of cores because you can't just hand a CPU some microcode and be done with it, you have to update each CPU core.
Borislav Petkov got a patch which updates CPU microcode in parallel into Linux 5.5. It's described as:
"This converts the late loading method to load the microcode in parallel (vs sequentially currently). The patch remained in linux-next for the maximum amount of time so that any potential and hard to debug fallout be minimized.
Now cloud folks have their milliseconds back but all the normal people should use early loading anyway :-)""
"Early loading" refers to microcode immediately after boot. The first kernel ring buffer line, which can be inspected using the dmesg command, will typically something like microcode: microcode updated early to revision 0x38, date = 2019-01-15. A cloud provider is not going to reboot hundres of 64-core systems with 200+ customer containers on each unless it is absolutely necessary.
NVMe Temperature Monitoring[edit]
There is a small utility called nvme which will let you read a NVMe drive's temperature. It requires root access and it does not play well (or at all) with standard system utilities like sensors from the lm_sensors package. Kernel 5.5 adds NVMe temperature to the HWMON infrastructure most fan and temperature-related things use. The new NVME_HWMON Kconfig option defaults to N. GNU/Linux distributions will probably enable it in their kernels.
Using a NVMe drive's temperature to control things like case fans using fancontrol from the lm_sensors package or other software may not make that much sense - but it's great to have the option. People do custom things, I use the GPU temperature to control my case's bottom intake fan.
Initial Intel Lightning Mountain SoC Support[edit]
Linux 5.4 brought some initial support for Intel's "Tiger Lake" platform. Linux 5.5 has new GPIO support for "Tiger Lake" (PINCTRL_TIGERLAKE) and a new pinctrl and GPIO driver for Intel "Lightning Mountain SoC" (PINCTRL_EQUILIBRIUM). A patch-set with eMMC PHY support for the "Lightning Mountain" SOC is kicking around on the LKML (it may or may not get merged later in the 5.5 release-cycle). That "Lightning Mountan" has a eMMC flash storage PHY built into it indicates that it is a SOC chip meant for something like smartphones, tablets or ultrabooks. Your guess is as good as ours.
AMD Graphics Goodies[edit]
Linux 5.5 brings HDCP support for AMD graphics cards. Digital restrictions management schemes are inherently bad but they are required to use some commercial television services so it is nice that support is there for those who really want to put chains and restrictions on their own devices.
Those who want to overclock AMD Navi graphics cards can now do it using the same /sys/class/drm/card0/device/ sysfs interfaces that previous generation graphics cards have to adjust voltages, clocks and other settings.
The Navi improvements do not stop there. Support for 8K monitors has been greatly improved. The amdgpu driver can now figure out if there is too little bandwidth for things like HDR between the graphics card and the display (cable/differing standards/etc) and revert to a less demanding display-mode capable of 8K resolutions. There was a similar issue with 4K displays using HDMI some years back which was solved in the same fashion.
Intel Graphics Woes[edit]
Linux 5.5 has some initial support for gen12 graphics cards. It does not fix any of the major issues with Intel graphics that have plagued the last few kernel releases. Users of low-powered machines with chips like the Goldmount N4200, Kaby Lake R chips and some other chips need to use i915.enable_dc=0 with this kernel to avoid random freezes. A freeze can reliably be triggered by turning the screen off with xset dpms force off and waiting around 10 seconds on the affected systems. Users of Baytrail chips need to use intel_idle.max_cstate=1 to avoid freezes within 30 minutes of booting. That Baytrail bug has been open for half a decade and it will probably never be fixed.
Better Support For Logitech Devices[edit]
Kernel developer Hans de Goede has been making improvements to the kernel's handling of Logitech mice and keyboards for quite some time. Kernel 5.2 brought specific drivers to Logitech devices that had previously been supported by the universal Generic Human Interface Devices driver. Kernel 5.5 adds standardized keyboard backlight control through the kernel's standard /sys/class/leds API as well as support for the special G keys on Logitech keyboards[1]. The Logitech G15 gaming keyboard and the Logitech MX Master 3 Mouse[2] is added to the now long list of supported Logitech devices.
Raspberry Pi 4 Support[edit]
The Raspberry Pi 4 has, until now, required a special kernel. Linux 5.5 has Broadcom BCM2711 SoC support which means that Raspberry Pi 4 devices no longer need a "special" kernel. There is also support for other single board computers like the NanoPi Due2, RK3308 and the Ugoos AM6 in Linux 5.5.
Multi-Drive Btrfs RAID1 Support[edit]
Btrfs has several built-in RAID1 modes. The latest kernel supports Btrfs RAID1 using more than two devices. If you use two-drive RAID1 and one drive fails you're in a position where all your data is gone if the remaining drive fails. The new Btrfs RAID1 block profiles for 3 and 4 copies are called RAID1C34 in Linux 5.5.
Random AMD Problems Are Solved[edit]
RDRAND stops returning random values on older AMD CPUs after suspend and the Ryzen 3000 CPUs would simply not do RDRAND with the AGESA BIOS shipped when that CPU series launched. Linux 5.5 sanity checks if the RDRAND CPU instruction returns actual random data both when the machine boots and when it returns from suspend (that is when older AMD APUs start returning 0xFFFFFFFFFFFFFFFF when RDRAND is called). systemd got a workaround for these issues six months ago.
Availability[edit]
Linux 5.5 is available from kernel.org. Bigger non-LTS distributions will probably have it in their repositories sometime this week.
Footnotes[edit]
Enable comment auto-refresher