Linux Kernel 5.3 is released
The latest Linux kernel is the first kernel with support for AMDs Navi GPUs which were released this summer. It also adds support for a series of special umwait instructions present on upcoming low-power Intel x86 CPUs. These instructions allows CPUs to wait for processes using far less power than NOP (No Operation) loops. Intel has also added Speed Select support for their Xeon servers to this kernel. A new lightweight hypervisor called ACRN may be of interest to those developing very light IoT devices. There is also support for the Chinese x86 Zhaoxin CPU in Linux Kernel 5.3.
New kernel, new "make oldconfig" questions
The new low-power wait instructions will be found on Intel CPUs based on the Tremont micro-architecture. Intel asset Fenghua Yu had this to say about them when the patches with support were sent to to Linux mailing list:
"Today, if an application needs to wait for a very short duration they have to have spinloops. Spinloops consume more power and continue to use execution resources that could hurt its thread siblings in a core with hyperthreads. New instructions umonitor, umwait and tpause allow a low power alternative waiting at the same time could improve the HT sibling perform while giving it any power headroom. These instructions can be used in both user space and kernel space."
The new kernel adds support for the AMDs "Navi" family of GPUs released this summer as well as some mysterious unreleased Navi-based chips. A new version of the Mesa graphics stack is also required to use these cards. The Mesa 19.2 release candidates have support for Navi. The final Mesa 19.2 version scheduled to be released tomorrow.
The Zhaoxin CPUs which Linux Kernel 5.3 adds support for are not new. Zhaoxin has been around since 2013 and their KaisHeng family of CPUs was launched in 2018 so it is about time the Linux kernel adds support for their somewhat outdated chips made on a 28nm node.
Linux kernel author and taipan Linus Torvalds had this to say about the release:
"So we've had a fairly quiet last week, but I think it was good that we ended up having that extra week and the final rc8.
Even if the reason for that extra week was my travel schedule rather than any pending issues, we ended up having a few good fixes come in, including some for some bad btrfs behavior. Yeah, there's some unnecessary noise in there too (like the speling fixes), but we also had several last-minute reverts for things that caused issues.
One _particularly_ last-minute revert is the top-most commit (ignoring the version change itself) done just before the release, and while it's very annoying, it's perhaps also instructive.
What's instructive about it is that I reverted a commit that wasn't actually buggy. In fact, it was doing exactly what it set out to do, and did it very well. In fact it did it _so_ well that the much improved IO patterns it caused then ended up revealing a user-visible regression due to a real bug in a completely unrelated area.
The actual details of that regression are not the reason I point that revert out as instructive, though. It's more that it's an instructive example of what counts as a regression, and what the whole "no regressions" kernel rule means. The reverted commit didn't change any API's, and it didn't introduce any new bugs. But it ended up exposing another problem, and as such caused a kernel upgrade to fail for a user. So it got reverted.
The point here being that we revert based on user-reported _behavior_, not based on some "it changes the ABI" or "it caused a bug" concept. The problem was really pre-existing, and it just didn't happen to trigger before. The better IO patterns introduced by the change just happened to expose an old bug, and people had grown to depend on the previously benign behavior of that old issue.
And never fear, we'll re-introduce the fix that improved on the IO patterns once we've decided just how to handle the fact that we had a bad interaction with an interface that people had then just happened to rely on incidental behavior for before. It's just that we'll have to hash through how to do that (there are no less than three different patches by three different developers being discussed, and there might be more coming...). In the meantime, I reverted the thing that exposed the problem to users for this release, even if I hope it will be re-introduced (perhaps even backported as a stable patch) once we have consensus about the issue it exposed.
Take-away from the whole thing: it's not about whether you change the kernel-userspace ABI, or fix a bug, or about whether the old code "should never have worked in the first place". It's about whether something breaks existing users' workflow.
Anyway, that was my little aside on the whole regression thing. Since it's that "first rule of kernel programming", I felt it is perhaps worth just bringing it up every once in a while.
Other than that aside, I don't find a lot to really talk about last week. Drivers, networking (and network drivers), arch updates, selftests. And a few random fixes in various other corners. The appended shortlog is not overly long, and gives a flavor for the changes.
And this obviously means that the merge window for 5.4 is open, and I'll start doing pull requests for that tomorrow. I already have a number of them in my inbox, and I appreciate all the people who got that over and done with early,
Linus"
There is a very long and detailed list of the changes in Linux Kernel 5.3 at kernelnewbies.org.
The new kernel, as well as stable branches of older kernels, can be found at kernel.org.
published 2019-09-17 - last edited 2019-09-17
Enable comment auto-refresher