5 ms·

Linux 6.16: faster file systems, improved confidential memory, more Rust support

162 points by CrankyBear 1y ago

tombert 1y ago
I'm still kind of surprised that Linus ended up allowing Rust into the kernel. Good, but surprising. Looking forward to this release once it hits NixOS Unstable.
- xeonmc 1y ago
  A surprise, to be sure, but a welcome one.
- Alupis 1y ago
  My understanding is its contained to the "edges", mostly in drivers and not in the "core" kernel. Still interesting indeed.
  - preisschild 1y ago
    for now, due to gcc-rs not being completed yet and the rustc compiler not supporting every linux architecture
    - dralley 1y ago
      There's two gcc-based compilers for Rust, gcc-rs which is part of the gcc suite and written in C++, and rustc_codegen_gcc, which is an optional backend for the existing Rust compiler written in Rust which emits an intermediate representation that GCC can understand. rustc_codegen_gcc is much closer to completion.
  - lights0123 1y ago
    It surprised me that Linux 6.12's QR code generator is written in Rust and enabled in at least Arch and Fedora.
    - jeffbee 1y ago
      Why does the kernel need a QR code generator?
      - lights0123 1y ago
        https://www.phoronix.com/news/Linux-6.12-DRM-Panic-QR-Code https://www.phoronix.com/news/Linux-6.12-DRM-Panic-QR-Code
        infogulch 1y ago
        Oh that's pretty nifty. It's always been a pita to get data (logs, traces, metadata etc) off of a crashed system. This is less human readable, but any human that wants to read it will want the raw data anyway. Way easier to do this than try to run photos of a screen through OCR.
        deleted 1y ago
        [deleted]
      - Twirrim 1y ago
        A QR code can capture 3k of data, you can capture a lot of context and details in that, particularly if you apply a little bit of compression (and the kernel has compression algorithms embedded in it). More than can be captured on a screen normally, without it zooming out of sight.
        jeffbee 1y ago
        An 80x25 ascii display carries 2000 characters which isn't shabby. But yeah, a lot harder to photograph.
      - 6SixTy 1y ago
        Would most people rather have a cell phone picture of the screen for debug logs, or a QR code that has those logs ready to be scanned and copy/pasted?
- geodel 1y ago
  On that note seems like after ruckus about Hector Martin's PRs not getting merged, things are calm but progressing.
- dralley 1y ago
  Linus is pragmatic. His only hard rule is "don't break userspace", most everything else is contingent. From what I can tell, he views Rust for Linux as a social project as much as a technical one - attract new (and younger) developers into the kernel, which has become pretty "senior", force all of the "unwritten rules" to be written down, and break down some of the knowledge siloing and fiefdom behavior that has taken place over the years (by sharing it specifically with that younger group of developers). If you think about it, Rust for Linux is in some ways essentially an auditing committee reviewing all of the API interactions between kernel subsystems and forcing them to be properly defined and documented. Even if the Rust part were to fail (exceedingly unlikely at this point), it's a useful endeavour in those other respects. But of course, if Rust is successful at encoding all of those rules using the type system, that unlocks a lot of value in the kernel too. Most of the kernel code is in drivers, and it's typically written by less experienced kernel developers while being harder to review by maintainers that don't have background on or access to the hardware. So if you can get drivers written in Rust with APIs that are harder to misuse, that takes a big load off the maintainers.
  - tombert 1y ago
    I just remember how much shit he talked about C++, and I guess I assumed that that would carry over to Rust as well.
    - kstrauser 1y ago
      True, but the Rust language itself is tiny compared to C++. There are only a slim fraction of the edge cases to learn. Note that I'm not saying Rust is easy to learn. I found it to be so, but it's going to be different for everyone. I do firmly believe that it's far easier for the average dev to learn the core of Rust than the core of C++, with far fewer footguns along that path.
      - tombert 1y ago
        Oh I don't disagree with any of that, I like Rust. I was just surprised is all.
- marsven_422 1y ago
  [dead]
- knowitnone2 1y ago
  It's an experiment. If it goes well, great. If it doesn't, revert back. What's the harm?
terandle 1y ago
Seems like Linus should be able to tap someone else to do 6.17 while he is on vacation
- cyphar 1y ago
  That has been done in the past (GregKH has managed releases a few times) but he obviously feels it's not necessary this time.
arp242 1y ago
> If your Linux laptop doubles as a music player, another nice new feature is that you can now stream your audio over USB even while the rest of your system is asleep. That capability's been available in Android for a while, but now it's part of mainline Linux. How does that work? You still need some program to actually play the music (mpv, Sotify, whatnot)? Or what am I misunderstanding? Unfortunately there are no details in the article, and an interwebz search doesn't really show anything.
- barchar 1y ago
  It probably requires active standby/s0ix. Modern Intel chips actually don't officially support s3 at all anymore, only s0ix. The whole point is to support stuff like this
- RS-232 1y ago
  Maybe it’s using Wake-on-LAN where the network interface is alive while the rest of the system is dormant? Perhaps the music stream is encoded in magic packets?
  - arp242 1y ago
    I found [1], which says "For Qualcomm hardware where the USB audio can be offloaded to a dedicated audio DSP for handling the transfers to the USB host controller, this lessens the work of the main CPU cores and can help with power management so those CPU cores can hit lower power states or tackle other work. Other hardware vendors will hopefully follow suit in their support for the upstream support around USB audio offloading." So I think that it doesn't do anything for the average Linux laptop, and is mostly intended for certain (mobile) hardware? [1]: https://www.phoronix.com/news/Linux-6.16-USB-Audio-Offload https://www.phoronix.com/news/Linux-6.16-USB-Audio-Offload
- smashed 1y ago
  It's probably related to this: https://www.phoronix.com/news/Linux-6.16-QCOM-USB-Audio-OLOAD https://www.phoronix.com/news/Linux-6.16-QCOM-USB-Audio-OLOA... Audio usb offloading. Only supported on Qualcomm soc's. Article is misleading. Audio offloading is probably only useful to avoid waking the main CPU too often, so better battery management... CPU can remain sleeping a few microseconds longer, not all the time. Not something many will benefit.
mschuster91 1y ago
> If your Linux laptop doubles as a music player, another nice new feature is that you can now stream your audio over USB even while the rest of your system is asleep. That capability's been available in Android for a while, but now it's part of mainline Linux. I thought Android did that by just turning off all but one CPU core and suspend all processes not required for streaming + bluetooth? I really can't imagine how else that would work, other than essentially giving the whole audio file to the Bluetooth chip and let it handle streaming on its own... but I've never heard of a Bluetooth chipset capable of that, much less bluez actually being usable enough.
- techjamie 1y ago
  Since sleep suspends execution and keeps the RAM state, I suppose it isn't a huge stretch for the kernel to provide some mechanism by which a program can stay awake while execution of others is paused. I'm sure there are aspects that are hard to reason about which I'm simply unaware of, but the idea makes sense to me.
- cestith 1y ago
  It hands it off to a dedicated media playback DSP. Right now, only Qualcomm is supported but there’s hope that now that the mainline kernel supports it other hardware providers will offer a way the kernel can do that for them, too.
- barchar 1y ago
  On modern Intel systems sleep works the same as on android. You don't just ask the chipset for s3 anymore. I wouldn't be surprised if one core stayed awake. This is why tiger lake laptops had crummy battery life on Linux upon release (often on windows too). Without working s0ix they just never suspend, and old style s3 isn't really officially supported.
ElijahLynn 1y ago
The article mentions Linux pull requests. Does Linux contribution do actual pull requests now? Or is it still a mailing list? If the latter, why would they say pull request?
- justincormack 1y ago
  Its a terrible article.
- 5kg 1y ago
  It's subsystem maintainers asking Linus to pull from their branches, e.g. https://lkml.org/lkml/2025/7/29/291 https://lkml.org/lkml/2025/7/29/291
- tux3 1y ago
  Pull requests took their name from the git request-pull script (which actually predates Github by a couple years): https://github.com/git/git/commit/ab421d2c7886341c246544bc8dea43c66a44d909 https://github.com/git/git/commit/ab421d2c7886341c246544bc8d... It is called a pull request because you are asking someone to do a `git pull` from your branch.
- PhilipRoman 1y ago
  "Pull requests" can also be done via a mailing list (it's literally a request to pull from some URL, see git-request-pull). It is not common on LKML, but I've seen it used that way. I think it's mostly maintainers that use it among themselves, everyone else just mails patches.
  - cyphar 1y ago
    It's used by subsystem maintainers to request Linus pull their changes (it is literally the only mechanism Linus accepts from subsystem maintainers, outside of a few outliers like the -next tree). But yes, most regular developers don't use it -- it doesn't allow for inline patch-by-patch reviews like "git send-email" or "b4 send".
- cyphar 1y ago
  The term "pull request" comes from "git request-pull" which is the tool used by kernel subsystem maintainers to send emails to Linus to request he git pull from their branches (and merge them). This usage long predates the somewhat unrelated "pull request" feature of source forges (like GitHub) and is not confusing to kernel developers (the target audience of Linus's email). The analogy to GitHub-like "pull requests" in the kernel workflow is "git send-email" (or "b4 send" nowadays) which sends patch series as individual emails that can be reviewed inline as a plain-text email and are applied onto maintainers' trees (usually with something akin to "git cherry-pick"). I still find this system to be a superior method to GitHub's "pull requests" (you can send review comments to commit descriptions -- which I believe Gerrit supports, but GitHub definitely doesn't -- and everything is sanely threaded since it's all email). Here's an example pull request email from the start of the week[1], containing some VFS changes to be included in 6.17-rc1. [1]: https://lore.kernel.org/all/20250725-vfs-misc-599b4aef8eaa@brauner/ https://lore.kernel.org/all/20250725-vfs-misc-599b4aef8eaa@b...
jauntywundrkind 1y ago
Neat to see zero-copy networking get TX, after RX shipped a while ago. Good stuff. I wonder how it overlaps-with/interacts with the various kernel offloads? I forget if this is TCP only or UDP too: would be really nice with QUIC / HTTP3 to see more love for UDP. https://www.phoronix.com/news/Device-Memory-TCP-TX-Linux-6.16 https://www.phoronix.com/news/Device-Memory-TCP-TX-Linux-6.1... The filesystem Folio work has been yielding such amazing results. In general I'm just so impressed how much the storage subsystems keep improving! IO_Uring has totally changed the game in terms of iops delivered just on it's own. But then the various filesystems & upper level multi-queue support have also been consistently finding really nice wins. Folios have been incredible! https://lwn.net/Articles/1015320/ https://lwn.net/Articles/1015320/ EROFS added compressed metadata support, which is showing a 2.5X win for readdir(3) (reading files from a directory). Given it's use in awesome works like composefs for next-gen & content-addressed based container overlay type systems, this is a nice win. https://github.com/composefs/composefs https://github.com/composefs/composefs Probably my favorite new feature is AMDGPU user queue (userq) work. Rather than the driver having to build out all the future work, now userspace can directly build the work of stuff to be done, sprinkling in various fences and what not. Some very interesting potential for GPGPU & perhaps ML! https://www.phoronix.com/news/Mesa-25.2-High-Priority-USERQ https://www.phoronix.com/news/Mesa-25.2-High-Priority-USERQ https://www.phoronix.com/news/Linux-6.16-AMDGPU-User-Queues https://www.phoronix.com/news/Linux-6.16-AMDGPU-User-Queues The Kernel Newbies release log is one of my favorite things to read through. It wasn't bursting-at-the-seams with awesome as you sometimes get with releases, but 6.16 was still very fun. https://news.ycombinator.com/item?id=44717122 https://news.ycombinator.com/item?id=44717122 https://kernelnewbies.org/Linux_6.16 https://kernelnewbies.org/Linux_6.16
bpbp-mango 1y ago
> Perhaps the most popular Linux file system, Ext4, is also getting many improvements. These boosts include faster commit paths, large folio support, and atomic multi-fsblock writes for bigalloc filesystems. What these improvements mean, if you're not a file-system nerd, is that we should see speedups of up to 37% for sequential I/O workloads. nice to see ext4 still getting improvements
remexre 1y ago
> For starters, Linux now supports Intel Advanced Performance Extensions (APX). [...] This improvement means you'll see increased performance from next-generation Intel CPUs, such as the Lunar Lake processors and the Granite Rapids Xeon processors. This isn't actually right, is it? APX hasn't been released, to my knowledge.

162 points by CrankyBear 1y ago

I'm still kind of surprised that Linus ended up allowing Rust into the kernel. Good, but surprising. Looking forward to this release once it hits NixOS Unstable.

xeonmc 1y ago
A surprise, to be sure, but a welcome one.
Alupis 1y ago
My understanding is its contained to the "edges", mostly in drivers and not in the "core" kernel. Still interesting indeed.
- preisschild 1y ago
  for now, due to gcc-rs not being completed yet and the rustc compiler not supporting every linux architecture
  - dralley 1y ago
    There's two gcc-based compilers for Rust, gcc-rs which is part of the gcc suite and written in C++, and rustc_codegen_gcc, which is an optional backend for the existing Rust compiler written in Rust which emits an intermediate representation that GCC can understand. rustc_codegen_gcc is much closer to completion.
- lights0123 1y ago
  It surprised me that Linux 6.12's QR code generator is written in Rust and enabled in at least Arch and Fedora.
  - jeffbee 1y ago
    Why does the kernel need a QR code generator?
    - lights0123 1y ago
      https://www.phoronix.com/news/Linux-6.12-DRM-Panic-QR-Code https://www.phoronix.com/news/Linux-6.12-DRM-Panic-QR-Code
      - infogulch 1y ago
        Oh that's pretty nifty. It's always been a pita to get data (logs, traces, metadata etc) off of a crashed system. This is less human readable, but any human that wants to read it will want the raw data anyway. Way easier to do this than try to run photos of a screen through OCR.
        deleted 1y ago
        [deleted]
    - Twirrim 1y ago
      A QR code can capture 3k of data, you can capture a lot of context and details in that, particularly if you apply a little bit of compression (and the kernel has compression algorithms embedded in it). More than can be captured on a screen normally, without it zooming out of sight.
      - jeffbee 1y ago
        An 80x25 ascii display carries 2000 characters which isn't shabby. But yeah, a lot harder to photograph.
    - 6SixTy 1y ago
      Would most people rather have a cell phone picture of the screen for debug logs, or a QR code that has those logs ready to be scanned and copy/pasted?
geodel 1y ago
On that note seems like after ruckus about Hector Martin's PRs not getting merged, things are calm but progressing.
dralley 1y ago
Linus is pragmatic. His only hard rule is "don't break userspace", most everything else is contingent. From what I can tell, he views Rust for Linux as a social project as much as a technical one - attract new (and younger) developers into the kernel, which has become pretty "senior", force all of the "unwritten rules" to be written down, and break down some of the knowledge siloing and fiefdom behavior that has taken place over the years (by sharing it specifically with that younger group of developers). If you think about it, Rust for Linux is in some ways essentially an auditing committee reviewing all of the API interactions between kernel subsystems and forcing them to be properly defined and documented. Even if the Rust part were to fail (exceedingly unlikely at this point), it's a useful endeavour in those other respects. But of course, if Rust is successful at encoding all of those rules using the type system, that unlocks a lot of value in the kernel too. Most of the kernel code is in drivers, and it's typically written by less experienced kernel developers while being harder to review by maintainers that don't have background on or access to the hardware. So if you can get drivers written in Rust with APIs that are harder to misuse, that takes a big load off the maintainers.
- tombert 1y ago
  I just remember how much shit he talked about C++, and I guess I assumed that that would carry over to Rust as well.
  - kstrauser 1y ago
    True, but the Rust language itself is tiny compared to C++. There are only a slim fraction of the edge cases to learn. Note that I'm not saying Rust is easy to learn. I found it to be so, but it's going to be different for everyone. I do firmly believe that it's far easier for the average dev to learn the core of Rust than the core of C++, with far fewer footguns along that path.
    - tombert 1y ago
      Oh I don't disagree with any of that, I like Rust. I was just surprised is all.
marsven_422 1y ago
[dead]
knowitnone2 1y ago
It's an experiment. If it goes well, great. If it doesn't, revert back. What's the harm?

terandle 1y ago

Seems like Linus should be able to tap someone else to do 6.17 while he is on vacation

cyphar 1y ago
That has been done in the past (GregKH has managed releases a few times) but he obviously feels it's not necessary this time.

arp242 1y ago

> If your Linux laptop doubles as a music player, another nice new feature is that you can now stream your audio over USB even while the rest of your system is asleep. That capability's been available in Android for a while, but now it's part of mainline Linux. How does that work? You still need some program to actually play the music (mpv, Sotify, whatnot)? Or what am I misunderstanding? Unfortunately there are no details in the article, and an interwebz search doesn't really show anything.

barchar 1y ago
It probably requires active standby/s0ix. Modern Intel chips actually don't officially support s3 at all anymore, only s0ix. The whole point is to support stuff like this
RS-232 1y ago
Maybe it’s using Wake-on-LAN where the network interface is alive while the rest of the system is dormant? Perhaps the music stream is encoded in magic packets?
- arp242 1y ago
  I found [1], which says "For Qualcomm hardware where the USB audio can be offloaded to a dedicated audio DSP for handling the transfers to the USB host controller, this lessens the work of the main CPU cores and can help with power management so those CPU cores can hit lower power states or tackle other work. Other hardware vendors will hopefully follow suit in their support for the upstream support around USB audio offloading." So I think that it doesn't do anything for the average Linux laptop, and is mostly intended for certain (mobile) hardware? [1]: https://www.phoronix.com/news/Linux-6.16-USB-Audio-Offload https://www.phoronix.com/news/Linux-6.16-USB-Audio-Offload
smashed 1y ago
It's probably related to this: https://www.phoronix.com/news/Linux-6.16-QCOM-USB-Audio-OLOAD https://www.phoronix.com/news/Linux-6.16-QCOM-USB-Audio-OLOA... Audio usb offloading. Only supported on Qualcomm soc's. Article is misleading. Audio offloading is probably only useful to avoid waking the main CPU too often, so better battery management... CPU can remain sleeping a few microseconds longer, not all the time. Not something many will benefit.

mschuster91 1y ago

> If your Linux laptop doubles as a music player, another nice new feature is that you can now stream your audio over USB even while the rest of your system is asleep. That capability's been available in Android for a while, but now it's part of mainline Linux. I thought Android did that by just turning off all but one CPU core and suspend all processes not required for streaming + bluetooth? I really can't imagine how else that would work, other than essentially giving the whole audio file to the Bluetooth chip and let it handle streaming on its own... but I've never heard of a Bluetooth chipset capable of that, much less bluez actually being usable enough.

techjamie 1y ago
Since sleep suspends execution and keeps the RAM state, I suppose it isn't a huge stretch for the kernel to provide some mechanism by which a program can stay awake while execution of others is paused. I'm sure there are aspects that are hard to reason about which I'm simply unaware of, but the idea makes sense to me.
cestith 1y ago
It hands it off to a dedicated media playback DSP. Right now, only Qualcomm is supported but there’s hope that now that the mainline kernel supports it other hardware providers will offer a way the kernel can do that for them, too.
barchar 1y ago
On modern Intel systems sleep works the same as on android. You don't just ask the chipset for s3 anymore. I wouldn't be surprised if one core stayed awake. This is why tiger lake laptops had crummy battery life on Linux upon release (often on windows too). Without working s0ix they just never suspend, and old style s3 isn't really officially supported.

ElijahLynn 1y ago

The article mentions Linux pull requests. Does Linux contribution do actual pull requests now? Or is it still a mailing list? If the latter, why would they say pull request?

justincormack 1y ago
Its a terrible article.
5kg 1y ago
It's subsystem maintainers asking Linus to pull from their branches, e.g. https://lkml.org/lkml/2025/7/29/291 https://lkml.org/lkml/2025/7/29/291
tux3 1y ago
Pull requests took their name from the git request-pull script (which actually predates Github by a couple years): https://github.com/git/git/commit/ab421d2c7886341c246544bc8dea43c66a44d909 https://github.com/git/git/commit/ab421d2c7886341c246544bc8d... It is called a pull request because you are asking someone to do a `git pull` from your branch.
PhilipRoman 1y ago
"Pull requests" can also be done via a mailing list (it's literally a request to pull from some URL, see git-request-pull). It is not common on LKML, but I've seen it used that way. I think it's mostly maintainers that use it among themselves, everyone else just mails patches.
- cyphar 1y ago
  It's used by subsystem maintainers to request Linus pull their changes (it is literally the only mechanism Linus accepts from subsystem maintainers, outside of a few outliers like the -next tree). But yes, most regular developers don't use it -- it doesn't allow for inline patch-by-patch reviews like "git send-email" or "b4 send".
cyphar 1y ago
The term "pull request" comes from "git request-pull" which is the tool used by kernel subsystem maintainers to send emails to Linus to request he git pull from their branches (and merge them). This usage long predates the somewhat unrelated "pull request" feature of source forges (like GitHub) and is not confusing to kernel developers (the target audience of Linus's email). The analogy to GitHub-like "pull requests" in the kernel workflow is "git send-email" (or "b4 send" nowadays) which sends patch series as individual emails that can be reviewed inline as a plain-text email and are applied onto maintainers' trees (usually with something akin to "git cherry-pick"). I still find this system to be a superior method to GitHub's "pull requests" (you can send review comments to commit descriptions -- which I believe Gerrit supports, but GitHub definitely doesn't -- and everything is sanely threaded since it's all email). Here's an example pull request email from the start of the week[1], containing some VFS changes to be included in 6.17-rc1. [1]: https://lore.kernel.org/all/20250725-vfs-misc-599b4aef8eaa@brauner/ https://lore.kernel.org/all/20250725-vfs-misc-599b4aef8eaa@b...

jauntywundrkind 1y ago

Neat to see zero-copy networking get TX, after RX shipped a while ago. Good stuff. I wonder how it overlaps-with/interacts with the various kernel offloads? I forget if this is TCP only or UDP too: would be really nice with QUIC / HTTP3 to see more love for UDP. https://www.phoronix.com/news/Device-Memory-TCP-TX-Linux-6.16 https://www.phoronix.com/news/Device-Memory-TCP-TX-Linux-6.1... The filesystem Folio work has been yielding such amazing results. In general I'm just so impressed how much the storage subsystems keep improving! IO_Uring has totally changed the game in terms of iops delivered just on it's own. But then the various filesystems & upper level multi-queue support have also been consistently finding really nice wins. Folios have been incredible! https://lwn.net/Articles/1015320/ https://lwn.net/Articles/1015320/ EROFS added compressed metadata support, which is showing a 2.5X win for readdir(3) (reading files from a directory). Given it's use in awesome works like composefs for next-gen & content-addressed based container overlay type systems, this is a nice win. https://github.com/composefs/composefs https://github.com/composefs/composefs Probably my favorite new feature is AMDGPU user queue (userq) work. Rather than the driver having to build out all the future work, now userspace can directly build the work of stuff to be done, sprinkling in various fences and what not. Some very interesting potential for GPGPU & perhaps ML! https://www.phoronix.com/news/Mesa-25.2-High-Priority-USERQ https://www.phoronix.com/news/Mesa-25.2-High-Priority-USERQ https://www.phoronix.com/news/Linux-6.16-AMDGPU-User-Queues https://www.phoronix.com/news/Linux-6.16-AMDGPU-User-Queues The Kernel Newbies release log is one of my favorite things to read through. It wasn't bursting-at-the-seams with awesome as you sometimes get with releases, but 6.16 was still very fun. https://news.ycombinator.com/item?id=44717122 https://news.ycombinator.com/item?id=44717122 https://kernelnewbies.org/Linux_6.16 https://kernelnewbies.org/Linux_6.16

bpbp-mango 1y ago

> Perhaps the most popular Linux file system, Ext4, is also getting many improvements. These boosts include faster commit paths, large folio support, and atomic multi-fsblock writes for bigalloc filesystems. What these improvements mean, if you're not a file-system nerd, is that we should see speedups of up to 37% for sequential I/O workloads. nice to see ext4 still getting improvements

remexre 1y ago

> For starters, Linux now supports Intel Advanced Performance Extensions (APX). [...] This improvement means you'll see increased performance from next-generation Intel CPUs, such as the Lunar Lake processors and the Granite Rapids Xeon processors. This isn't actually right, is it? APX hasn't been released, to my knowledge.