Linux Kernel 6.16 Reaches End of Life, It’s Time to Upgrade to Linux Kernel 6.17

https://fed.brid.gy/r/https://9to5linux.com/linux-kernel-6-16-reaches-end-of-life-its-time-to-upgrade-to-linux-kernel-6-17

💡 Kernel Linux 6.16-rc3 porta miglioramenti driver e stabilità

https://gomoot.com/kernel-linux-6-16-rc3-porta-miglioramenti-driver-e-stabilita/

#blog #kernel #linux616 #news #picks #rc3 #tech #tecnologia

Linux 6.16 RC2 will fix the power regression!

Linux 5.15 was mistakenly shipped with code that caused power regression for non-SMT systems. That is, the systems that boot with the nosmt option. Since then, this code has been reverted as it could cause serious damage to the computers that use that option, starting from Linux 6.16 RC1 and 6.15.

Now, the patch has been re-introduced to Linux 6.16 RC2. This time, it’s implemented properly to prevent this power regression on non-SMT systems to avoid damages caused by this regression. The code has been fixed, and the below explanation has been provided:

Eliminate mwait_play_dead_cpuid_hint() again after reverting its elimination during the 6.16 merge window due to a problem with handling “dead” SMT siblings, but this time prevent leaving them in C1 after initialization by taking them online and back offline when a proper cpuidle driver for the platform has been registered

During initialization, the ACPI processor code needs to rescan the “dead” SMT siblings in a way that prevents leaving them in C1 after initialization. This is by taking those siblings online temporarily while waiting for a proper CPU idle driver to register itself before taking them back off.

Linux 6.16 RC2 will be released today at 9 PM GMT!

Image by marymarkevich on Freepik

#Fixes #Linux #Linux616 #news #Power #PowerManagement #Regression #Tech #Technology #update

💡 Linux 6.16-rc1, verso un kernel più moderno e robusto

https://gomoot.com/linux-6-16-rc1-verso-un-kernel-piu-moderno-e-robusto

#amd #blog #driver #intel #kernel #linux #linux616 #news #nvidia #picks #rc1 #riscv #rust #tech #tecnologia

Linux 6.16 yields improved EXT4 performance!

As part of the changes that are done in Linux 6.16, there are some of the very interesting changes that are done to the EXT4 filesystem. Those changes yield improved performance, causing you to have a faster EXT4 filesystem compared to the recently released Linux 6.15.

Those changes have been made to improve the filesystem performance, which will be pushed to the v6.16 development branch from this PR, including:

• Fast commit performance improvements
• Multi-fsblock atomic write support for bigalloc file systems
• Large folio support for regular files

The large folio support for regular files was, in itself, a factor of the improvements, along with all other changes, which yielded over 37% performance increase according to the kernel test robot that made this report you can see here. According to the test robot, it has reported that it had noticed a 37.7% improvement on fsmark.files_per_sec.

The large folio support for regular files has been added with this patch, which checks for the following conditions in the ext4_should_enable_large_folio() function before enabling such support:

• If i_mode on an inode is a regular file using the S_ISREG() macro
• If either the data flags on the superblock or the inode flags has the journal data flags
• If the superblock has no verity and has no encryption support

Also, Linux 6.16 fixes some corruption bugs on an EXT4 file system caused by race conditions in the extent status tree. Those race conditions were potentially manifested from the heavy simultaneous allocation and deallocation to a single file.

Expect the first release candidate of Linux 6.16 in the next two weeks!

#EXT4 #Filesystem #Linux #Linux616 #LinuxKernel #news #Tech #Technology #update

A document describes techniques that are useful for debugging suspend and resume issues with modern #AMD processors was merged for #Linux 6.16: https://git.kernel.org/torvalds/c/cafb22242bfb7fad10fde6f9b99853fc924e691a

Rendered version: https://origin.kernel.org/doc/html/next/arch/x86/amd-debugging.html

#kernel #LinuxKernel #Ryzen #Epyc #Linux616

Support task local hash maps[1], FUTEX2_NUMA[2], and FUTEX2_MPOL[3] was merged for #Linux 6.16:

https://git.kernel.org/torvalds/c/b3570b00dc3062c5a5e8d9602b923618d679636a

See also: https://lore.kernel.org/all/2025041616[email protected]/

[1] https://git.kernel.org/torvalds/c/80367ad01d93ac781b0e1df246edaf006928002f

[2] https://git.kernel.org/torvalds/c/cec199c5e39bde7191a08087cc3d002ccfab31ff

[3] https://git.kernel.org/torvalds/c/c042c505210dc3453f378df432c10fff3d471bc5

#kernel #LinuxKernel #Linux616

A option to optimize the code for the local CPU was merged for #Linux 6.16:

https://git.kernel.org/torvalds/c/ea1dcca1de129dfdf145338a868648bc0e24717c

To quote: '"Add a 'native' option that allows users to build an optimized kernel for their local machine (i.e. the machine which is used to build the kernel) by passing '-march=native' to CFLAGS.

The idea comes from Linus' reply to Arnd's initial proposal:

https://lore.kernel.org/all/CAHk-=wji1[email protected]/

Here are some numbers comparing 'generic' to 'native' on a Skylake dual-core laptop (generic --> native) […]
There is little difference both in terms of size and of performance, however
the native build comes out on top ever so slightly [3 % in some cases]."'

Note, the author tried in on a different machine later, and there it made no real difference:

https://lore.kernel.org/all/b67fad41-3[email protected]/

#kernel #LinuxKernel #Linux616

Highlights from the main #erofs merge for #Linux 6.16 (https://git.kernel.org/torvalds/c/79b98edf918e8146047e08817e2a42937428be02):

* a `fsoffset` mount option is introduced for file-backed mounts to specify the filesystem offset in order to adapt customized container formats.

* Intel QAT hardware accelerators are supported to improve DEFLATE decompression performance.

#kernel #LinuxKernel #Linux616 #filesystem