Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

Linux kernel 6.1 is out now

By - | Views: 28,599

Linus Torvalds has officially released the Linux kernel 6.1, and as usual there's absolutely tons of new features and fixes.

From the announcement "So here we are, a week late, but last week was nice and slow, and I'm much happier about the state of 6.1 than I was a couple of weeks ago when things didn't seem to be slowing down.". Torvalds also mentioned he will "be pretty strict about the merge window rules" as the plan is to have a calm holiday season.

As for some of what's new:

  • Initial support for the Rust language.
  • Btrfs file system performance improvements.
  • Various Intel Arc graphics improvements.
  • More work for AMD RDNA3 GPUs.
  • Intel Meteor Lake Thunderbolt support.
  • Support for more sound systems.
  • Support for Xbox One Elite Controller paddles.
  • Better support of Nintendo clone controllers.
  • Initial DualSense Edge controller support
  • Lots more the list is very long.

For more in-depth info you can check out the usual Phoronix report and LWN Part 1 and Part 2 or wherever else you generally get your kernel news from. The full changelog is available over here.

Article taken from GamingOnLinux.com.
21 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
20 comments
Page: 1/2»
  Go to:

CatKiller Dec 12, 2022
View PC info
  • Supporter Plus
The Rust support is going particularly well, since the new M1 stuff is being done in Rust and Linus himself is using an M1 machine. He said that the Rust support would have to be used so that it would actually be tested properly, and he's in a position to do that personally.
ExpandingMan Dec 12, 2022
We don't know what the next LTS version is going to be, do we? I would stay on latest if it weren't for nvidia, but the nvidia drivers always make me nervous about updating the kernel.
ExpandingMan Dec 12, 2022
We don't know what the next LTS is going to be do we? I would stay on latest, but the nvidia drivers make me nervous.
CatKiller Dec 12, 2022
View PC info
  • Supporter Plus
Quoting: ExpandingManWe don't know what the next LTS version is going to be, do we? I would stay on latest if it weren't for nvidia, but the nvidia drivers always make me nervous about updating the kernel.
Since DKMS became a thing, the Nvidia driver doesn't really care about kernel version. The module gets built against the kernel you have. Every now and then there's an issue with the driver having problems with building against a kernel that's newer than expected, but a new driver version tends to get rolled out quickly when that happens.
ExpandingMan Dec 12, 2022
I've had problems in the past, but it's been a while. Perhaps I was being unnecessarily cautious, I'll experiment with 6.1.
slaapliedje Dec 12, 2022
Quoting: ExpandingManI've had problems in the past, but it's been a while. Perhaps I was being unnecessarily cautious, I'll experiment with 6.1.
Historically, nvidia has been way better at this than AMD. When the FireGL drivers were a thing, you'd upgrade your system and the driver would be broken for months, either from a kernel upgrade or Xorg. I maintain this is the real reason they mainlined it into the kernel / mesa. They just didn't have the manpower to maintain a separate driver. It's also likely the reason they had like 4 different drivers at some point.
ExpandingMan Dec 12, 2022
Just booted into 6.1 (actually it's an RC because the repos don't have latest yet) with no problems.

I tend to forget how incredibly easy Manjaro makes it to switch kernels.
F.Ultra Dec 12, 2022
View PC info
  • Supporter
Quoting: Guest
QuoteBtrfs file system performance improvements.
Is long mounting of large HDD partitions fixed now?

What counts as large partitions and long time? I use BTRFS on several servers each with 153TB per partition and mounting is sub second and have been for many years.

edit: that said one of the listed items is improved mount times on large systems:

QuoteHi,

please pull the following updates for btrfs. There's a bunch of
performance improvements, most notably the FIEMAP speedup, the new block
group tree to speed up mount on large filesystems, more io_uring
integration, some sysfs exports and the usual fixes and core updates.

Thanks.

---

Performance:

- outstanding FIEMAP speed improvement
- algorithmic change how extents are enumerated leads to orders of
magnitude speed boost (uncached and cached)
- extent sharing check speedup (2.2x uncached, 3x cached)
- add more cancellation points, allowing to interrupt seeking in files
with large number of extents
- more efficient hole and data seeking (4x uncached, 1.3x cached)
- sample results:
256M, 32K extents: 4s -> 29ms (~150x)
512M, 64K extents: 30s -> 59ms (~550x)
1G, 128K extents: 225s -> 120ms (~1800x)

- improved inode logging, especially for directories (on dbench workload
throughput +25%, max latency -21%)

- improved buffered IO, remove redundant extent state tracking, lowering
memory consumption and avoiding rb tree traversal

- add sysfs tunable to let qgroup temporarily skip exact accounting when
deleting snapshot, leading to a speedup but requiring a rescan after
that, will be used by snapper

- support io_uring and buffered writes, until now it was just for direct
IO, with the no-wait semantics implemented in the buffered write path
it now works and leads to speed improvement in IOPS (2x), throughput
(2.2x), latency (depends, 2x to 150x)

- small performance improvements when dropping and searching for extent
maps as well as when flushing delalloc in COW mode (throughput +5MB/s)

User visible changes:

- new incompatible feature block-group-tree adding a dedicated tree for
tracking block groups, this allows a much faster load during mount and
avoids seeking unlike when it's scattered in the extent tree items
- this reduces mount time for many-terabyte sized filesystems
- conversion tool will be provided so existing filesystem can also be
updated in place
- to reduce test matrix and feature combinations requires no-holes
and free-space-tree (mkfs defaults since 5.15)

- improved reporting of super block corruption detected by scrub

- scrub also tries to repair super block and does not wait until next
commit

- discard stats and tunables are exported in sysfs
(/sys/fs/btrfs/FSID/discard)

- qgroup status is exported in sysfs (/sys/sys/fs/btrfs/FSID/qgroups/)

- verify that super block was not modified when thawing filesystem

Fixes:

- FIEMAP fixes
- fix extent sharing status, does not depend on the cached status where
merged
- flush delalloc so compressed extents are reported correctly

- fix alignment of VMA for memory mapped files on THP

- send: fix failures when processing inodes with no links (orphan files
and directories)

- fix race between quota enable and quota rescan ioctl

- handle more corner cases for read-only compat feature verification

- fix missed extent on fsync after dropping extent maps

Core:

- lockdep annotations to validate various transactions states and state
transitions

- preliminary support for fs-verity in send

- more effective memory use in scrub for subpage where sector is smaller
than page

- block group caching progress logic has been removed, load is now
synchronous

- simplify end IO callbacks and bio handling, use chained bios instead
of own tracking

- add no-wait semantics to several functions (tree search, nocow,
flushing, buffered write

- cleanups and refactoring

MM changes:

- export balance_dirty_pages_ratelimited_flags


Last edited by F.Ultra on 12 December 2022 at 11:40 pm UTC
slaapliedje Dec 12, 2022
Quoting: F.Ultra
Quoting: Guest
QuoteBtrfs file system performance improvements.
Is long mounting of large HDD partitions fixed now?

What counts as large partitions and long time? I use BTRFS on several servers each with 153TB per partition and mounting is sub second and have been for many years.

edit: that said one of the listed items is improved mount times on large systems:

QuoteHi,

please pull the following updates for btrfs. There's a bunch of
performance improvements, most notably the FIEMAP speedup, the new block
group tree to speed up mount on large filesystems, more io_uring
integration, some sysfs exports and the usual fixes and core updates.

Thanks.

---

Performance:

- outstanding FIEMAP speed improvement
- algorithmic change how extents are enumerated leads to orders of
magnitude speed boost (uncached and cached)
- extent sharing check speedup (2.2x uncached, 3x cached)
- add more cancellation points, allowing to interrupt seeking in files
with large number of extents
- more efficient hole and data seeking (4x uncached, 1.3x cached)
- sample results:
256M, 32K extents: 4s -> 29ms (~150x)
512M, 64K extents: 30s -> 59ms (~550x)
1G, 128K extents: 225s -> 120ms (~1800x)

- improved inode logging, especially for directories (on dbench workload
throughput +25%, max latency -21%)

- improved buffered IO, remove redundant extent state tracking, lowering
memory consumption and avoiding rb tree traversal

- add sysfs tunable to let qgroup temporarily skip exact accounting when
deleting snapshot, leading to a speedup but requiring a rescan after
that, will be used by snapper

- support io_uring and buffered writes, until now it was just for direct
IO, with the no-wait semantics implemented in the buffered write path
it now works and leads to speed improvement in IOPS (2x), throughput
(2.2x), latency (depends, 2x to 150x)

- small performance improvements when dropping and searching for extent
maps as well as when flushing delalloc in COW mode (throughput +5MB/s)

User visible changes:

- new incompatible feature block-group-tree adding a dedicated tree for
tracking block groups, this allows a much faster load during mount and
avoids seeking unlike when it's scattered in the extent tree items
- this reduces mount time for many-terabyte sized filesystems
- conversion tool will be provided so existing filesystem can also be
updated in place
- to reduce test matrix and feature combinations requires no-holes
and free-space-tree (mkfs defaults since 5.15)

- improved reporting of super block corruption detected by scrub

- scrub also tries to repair super block and does not wait until next
commit

- discard stats and tunables are exported in sysfs
(/sys/fs/btrfs/FSID/discard)

- qgroup status is exported in sysfs (/sys/sys/fs/btrfs/FSID/qgroups/)

- verify that super block was not modified when thawing filesystem

Fixes:

- FIEMAP fixes
- fix extent sharing status, does not depend on the cached status where
merged
- flush delalloc so compressed extents are reported correctly

- fix alignment of VMA for memory mapped files on THP

- send: fix failures when processing inodes with no links (orphan files
and directories)

- fix race between quota enable and quota rescan ioctl

- handle more corner cases for read-only compat feature verification

- fix missed extent on fsync after dropping extent maps

Core:

- lockdep annotations to validate various transactions states and state
transitions

- preliminary support for fs-verity in send

- more effective memory use in scrub for subpage where sector is smaller
than page

- block group caching progress logic has been removed, load is now
synchronous

- simplify end IO callbacks and bio handling, use chained bios instead
of own tracking

- add no-wait semantics to several functions (tree search, nocow,
flushing, buffered write

- cleanups and refactoring

MM changes:

- export balance_dirty_pages_ratelimited_flags
I wonder how long it would take me to fill up 153TB with my Steam Library on my 2gbit fiber line...
Linas Dec 13, 2022
View PC info
  • Supporter Plus
https://kernelnewbies.org/LinuxChanges is my favorite site for keeping up to date with changes in the Linux kernel.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.