Last night I published some benchmarks after finding Linux 4.20 is regressing in several workloads compared to Linux 4.18/4.19 and at least was affecting Intel Core i9 "HEDT" boxes. Here are more affected workloads regressing on Linux 4.20 and it's not just limited to high-end hardware.

Being well past the Linux 4.20 merge window I have moved onto benchmarking more of this development version of the Linux kernel. Unfortunately, there are some clear performance regressions.

Con Kolivas is out with an updated version of his MuQSS scheduler (based on his former Brain BFS Scheduler work) as well as his "-ck" patch-set against the mainline kernel.

As new system calls get added to the Linux kernel, these syscalls generally get added to Glibc (and other libc libraries) for developers to make easy use of them from their applications. But as Glibc doesn't provide 1:1 coverage of system calls, sometimes is delayed in their support for new calls, and other factors, there is a discussion about providing an official Linux system wrapper library that could potentially live as part of the kernel source tree.

Linus Torvalds put out the second weekly test release of the Linux 4.20 kernel and all-around it's been a normal week past the merge window.

Last month I reported on a number of fixes for really old bugs in the EXT4 code with some of the issues dating back to the Linux 2.6 days in the EXT3 file-system code that was carried over to the EXT4 driver. Those fixes are now working their way into the Linux 4.20 stable kernel.

For more than a year it's been talked about adding an option to support Zstd-compressed Linux kernel images while it looks like that Facebook-backed high performance compression algorithm for kernel images could soon finally be mainlined.

With the Linux 4.20 merge window having ended this past weekend, the first big batch of new feature material to DRM-Next from the "DRM-Misc" area has been submitted for the follow-on Linux 4.21 cycle.

It's been just about one year since the last patch series was sent out while on Monday marked a new revision to KTask, the effort that provides a generic framework to parallelize CPU-intensive kernel work.

The next kernel release was either going to be Linux 4.20 or Linux 5.0 and today Linus Torvalds decided it would be the "4.20" kernel version.

Greg Kroah-Hartman this morning released Linux 4.19.1 as the first point release to Linux 4.19 that debuted two weeks ago today.

The Linux kernel will be ending 2018 on a high note with the current merge window for what will be called either Linux 4.20 or Linux 5.0 is the biggest kernel update by lines of code in more than one year.

While there are a lot of great new features, hardware support improvements, and other changes with the Linux 4.20 development cycle, not found in this mainline kernel is the long-awaited WireGuard functionality for an in-kernel secure VPN tunnel.

With the Linux 4.20~5.0, the kernel is now VLA-free as a step towards being able to compile the mainline code with the LLVM Clang compiler or other non-GCC compilers. Another step in this direction has been merged this cycle and that is cleaning up the compiler attributes code.

As part of the big DRM pull request for the next Linux kernel cycle, the AMDGPU driver enabled GFXOFF and Stutter Mode functionality for Raven Ridge. But this power-savings functionality is already being reverted for the next kernel release.

A Google developer has proposed /proc/pid/kill as a new procfs-based kill interface for killing a process on Linux.

Adding to the big list of changes for Linux 4.20~5.0 is a number of updates within the kernel's staging area.

While we still don't know yet whether Linus Torvalds intends to call this next kernel Linux 4.20 or Linux 5.0, we do know that whatever the version ends up being, this is going to be a very big kernel release with a lot of new features.

With the in-development Linux 4.20 kernel, it is now effectively VLA-free... The variable-length arrays (VLAs) that can be convenient and part of the C99 standard but can have unintended consequences.

When Linus Torvalds announced last month that he would be taking a temporary leave of absence to work on his empathy and interpersonal skills as well as the adoption of a Linux kernel Code of Conduct, some Internet commenters thought this would lead Linus to being less strict about code quality and his standards for accepting new code to the mainline tree. Fortunately, he's shown already for the new Linux 4.20~5.0 cycle he isn't relaxing his standards but is communicating better when it comes to bringing up coding issues.

Introduced in the Linux 4.18 kernel was the Restartable Sequences "rseq" system call intended to yield faster user-space operations on per-CPU data. As covered during a presentation at this week's Open-Source Summit Europe, that system call is indeed providing performance wins while it's not widely utilized yet.

In the past number of years have been a lot of changes in prepping the kernel for Year 2038, but that work still isn't over and with the in-development Linux 4.20~5.0 kernel are yet more time keeping changes for prepping for this Y2K-like event.

Greg Kroah-Hartman began sending in his feature pull requests this morning for the newly-started Linux 4.20~5.0 kernel cycle.

The next Linux kernel has scheduler improvements that will benefit some tasks when running on ARM big.LITTLE type systems where select CPU cores are much more powerful than the other cores.

Across Ingo Molnar 's x86-focused kernel branches (including x86 64-bit) there are some performance optimizations to note in this new material for Linux 4.20~5.0.

David Airlie has submitted the main feature pull request of the plethora of Direct Rendering Manager (DRM) enhancements for the next kernel release that includes a lot of Intel and AMD Radeon graphics driver work.

Going back several release cycles has been an effort to add the XArray data structure to the Linux kernel but to date that hasn't happened. It wasn't accepted for Linux 4.19 and now Matthew Wilcox -- who began this work about two years ago as a programmer at Microsoft -- is hoping Linux 4.20~5.0 will be the lucky release.

Intel's Rafael Wysocki sent in the power management updates today for the Linux 4.20~5.0 kernel cycle.

It's not often we get to talk about the LED drivers for the Linux kernel... Yes, the class of Linux kernel drivers to support controlling the brightness of LEDs via supported drivers and exposing that to user-space. With Linux 4.20~5.0 comes finally the ability to program "patterns" for LEDs.

There is already a lot of features slated for the Linux 4.20~5.0 kernel with its development cycle officially having gotten underway this morning. Adding to that lengthy list of expected work is the possible introduction of the I3C subsystem.