Search
320 results for “kernellogger”
-
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
""WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V""
Linus send that to #LKML a few hours ago, after somebody asked if some of the big-endian work will make it into #Linux 6.18.
For the full thread, see: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%[email protected]/t/#mce138059dc56014643bbda330810183031ef5c06
There he calls the reasons documented on riscv.org as "craziness" and insane:
""In other words, it is suggesting that RISC-V add a big-endian mode due to
(a) internet protocols - where byte swapping is not an issue
(b) using "some RISC-V implementations don't do the existing Zbb extension" as an excuse
This is plain insanity. First off, even if byte swapping was a real cost for networking - it's not, the real costs tend to be all in memory subsystems - just implement the damn Zbb extension.""
-
"An explanation of how #Linux handles system calls on x86-64 and why they show up as expensive operations in performance profiles
https://blog.codingconfessions.com/p/what-makes-system-calls-expensive – from Abhinav Upadhyay
-
The #Rust based #Tyr driver[1] for #Arm #Mali GPUs has reached #linux-next today and thus is slated for inclusion in #kernel 6.18:
Congrats to everyone involved!
""It is a port of #Panthor and therefore exposes Panthor's uAPI and name to userspace, and the product of a joint effort between Collabora, Arm and Google engineers.
The aim is to incrementally develop Tyr with the abstractions that are currently available until it is consider to be in parity with Panthor feature-wise. […]""
[1] https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html
-
The #Rust based #Tyr driver[1] for #Arm #Mali GPUs has reached #linux-next today and thus is slated for inclusion in #kernel 6.18:
Congrats to everyone involved!
""It is a port of #Panthor and therefore exposes Panthor's uAPI and name to userspace, and the product of a joint effort between Collabora, Arm and Google engineers.
The aim is to incrementally develop Tyr with the abstractions that are currently available until it is consider to be in parity with Panthor feature-wise. […]""
[1] https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html
-
The #Rust based #Tyr driver[1] for #Arm #Mali GPUs has reached #linux-next today and thus is slated for inclusion in #kernel 6.18:
Congrats to everyone involved!
""It is a port of #Panthor and therefore exposes Panthor's uAPI and name to userspace, and the product of a joint effort between Collabora, Arm and Google engineers.
The aim is to incrementally develop Tyr with the abstractions that are currently available until it is consider to be in parity with Panthor feature-wise. […]""
[1] https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html
-
The #Rust based #Tyr driver[1] for #Arm #Mali GPUs has reached #linux-next today and thus is slated for inclusion in #kernel 6.18:
Congrats to everyone involved!
""It is a port of #Panthor and therefore exposes Panthor's uAPI and name to userspace, and the product of a joint effort between Collabora, Arm and Google engineers.
The aim is to incrementally develop Tyr with the abstractions that are currently available until it is consider to be in parity with Panthor feature-wise. […]""
[1] https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html
-
The #Rust based #Tyr driver[1] for #Arm #Mali GPUs has reached #linux-next today and thus is slated for inclusion in #kernel 6.18:
Congrats to everyone involved!
""It is a port of #Panthor and therefore exposes Panthor's uAPI and name to userspace, and the product of a joint effort between Collabora, Arm and Google engineers.
The aim is to incrementally develop Tyr with the abstractions that are currently available until it is consider to be in parity with Panthor feature-wise. […]""
[1] https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html
-
Mitigations for #vmscape have been merged to #Linux mainline and included in new stable and longterm #kernel versions released about an hour ago (like 6.16.7 or 6.12.47).
Vmscape is a vulnerability that essentially takes Spectre-v2 and attacks host userspace from a guest. It particularly affects hypervisors like #QEMU.
For more details see this #LinuxKernel merge commit https://git.kernel.org/torvalds/c/223ba8ee0a3986718c874b66ed24e7f87f6b8124, the doc changes in contains at https://git.kernel.org/torvalds/c/9969779d0803f5dcd4460ae7aca2bc3fd91bff12, or the following page from those that published the vulnerability:
It is tracked as #CVE-2025-40300
-
Recording (https://www.youtube.com/watch?v=05gfIRahZA8 ) and slides (https://static.sched.com/hosted_files/osseu2025/e4/OSS-EU25-Werner-Fischer-The-Power-of-theDevice-Mapper.pdf ) from Werner Fischer's #OSSEU25 talk "The Power of the #DeviceMapper - From Dm-cache To Dm-zoned" are now online.
From the abstract: "The device mapper has been part of the #LinuxKernel since #kernel version 2.6. It allows the creation of virtual block devices by mapping their address space to other block devices or special functions. In this way, it can map physical block devices such as hard disks or SSDs to higher-level virtual block devices. It is the basis for the Logical Volume Manager (LVM), #Linux software RAIDs and dm-crypt encryption, and provides additional features such as file system snapshots.
However, the use of Device Mapper targets is not limited to that. Many other targets offer often unknown features. Most of these are intended for production use. However, there are also some targets designed specifically for debugging.
In this talk, Werner gives a full overview of all Device Mapper targets.
For production use these are: dm-cachd, dm-clone, dm-crypt, dm-ebs, dm-era, dm-integrity, dm-linear, dm-mirror, dm-raid, dm-stripe, dm-switch, dm-thin, dm-unstripe, dm-verity, dm-vdo, dm-writecache and dm-zoned.
For debugging: dm-delay, dm-dust, dm-flakey and dm-zero.
He also briefly shows drbd, md (RAID) and bcache, which, like device mapper targets, can work as devices "on top" of normal block devices."
-
Recording (https://www.youtube.com/watch?v=D-gBQ_giJrI ) and slides (https://static.sched.com/hosted_files/osseu2025/49/oss-slides-pw-v2.pdf ) from Kundan Kumar's #OSSEU25 talk "Rethinking Writeback: Scaling #Linux Filesystem and Memory Performance for the Next Decade" are now online.
From the abstract: "Linux’s current writeback infrastructure, while robust, was designed before large folios, CXL-tiered memory, and AI workloads demanding low-latency, high-throughput I/O. Today, workloads like RAG pipelines using vector databases with buffered I/O, and memory tiering on CXL, are exposing scalability limits in how the #kernel handles writeback.
This talk presents a forward-looking view on evolving Linux’s writeback model. We’ll explore how the single-threaded design stalls page migration and reduces memory compaction effectiveness—affecting hugepage allocations and folio movement across memory tiers, contributing to fragmentation. On the storage side, parallelizing writeback improves throughput and responsiveness under dirty-page pressure, especially for sustained-write workloads with large memory footprints on High capacity SSDs.
We’ll also touch on early experiments within the kernel community, including efforts to make writeback more filesystem-geometry aware and parallelize it based on overwrites/new allocations.
This session invites open source community to reimagine writeback as a scalable, performance-critical component in Linux. […]"
https://osseu2025.sched.com/event/25VmH/rethinking-writeback-scaling-linux-filesystem-and-memory-performance-for-the-next-decade-kundan-kumar-samsung-rd-institute-india #LinuxKernel
-
Recording (https://www.youtube.com/watch?v=O8Q8nIzEG6c ) and slides (https://static.sched.com/hosted_files/osseu2025/b3/pdx86-community-health-2025.pdf ) from Hans de Goede's #OSSEU25 talk "Creating a Healthy Vibrant [#Linux] #Kernel Subsystem Community" are now online.
From the abstract: "End 2020 I became the maintainer of the drivers/platform/x86 (pdx86) kernel subsytem. The subject of this talk is my experience in creating a friendly welcoming environment, growing the pdx86 community and how this helped me to avoid burnout by being able to delegate to community members."
https://osseu2025.sched.com/event/25VmE/creating-a-healthy-vibrant-kernel-subsystem-community-hans-de-goede-red-hat #LinuxKernel
-
""The name sure sounds like “mutex”, and that is where the name comes from: “fast, user space mutex”. But, it isn’t really, it’s a building block for concurrency primitives that ushered in a modern world of concurrent performance […]
t was immediately clear that the futex was a huge improvement in highly concurrent environments. Just in that original paper, their tests with 1000 parallel tasks ran 20-120 times faster than sysv locks..🤯
Needless to say, other common operating systems followed suit, including Windows in 2012 and macOS by 2016.
These days, any good locking primitive is going to be based on a futex. […]""
-
Introduction to VirtIO, Part 2: Vhost
https://blogs.oracle.com/linux/post/introduction-to-virtio-part-2-vhost
Jonah Palmer writes: ""[…] #Vhost is a key optimization to #VirtIO that was created to offload data-plane processing from #Qemu into more efficient components.
We’ll start off by taking a more in-depth look into the causes of overhead in the data plane of a pure VirtIO configuration. We’ll talk about the costly operations that are involved, such as VM exits, VM entries, context switches, and userspace processing by Qemu. Then we’ll introduce vhost and elaborate on how it addresses these issues by moving data-plane operations either into the kernel (kernel-based vhost) or into a specialized userspace process (via vhost-user).
We’ll then dive into both #kernel-based vhost and vhost-user architectures, examining each in detail—including their advantages, drawbacks, typical use cases, and how they affect performance. […]"
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Linus still did neither remove bcachefs from #Linux #kernel nor pulled the updates for 6.17 Kent submitted.
The latter meanwhile wrote a few mails to #LKML which in diplomatic phrases might be called "not really helpful", like this one https://lore.kernel.org/all/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
It resulted in a few good replies from respected developers that are worth a read if you are followed the topic, among them from Josef Bacik (https://lore.kernel.org/all/20250809192156.GA1411279@fedora/ ), Matthew Wilcox (https://lore.kernel.org/all/aJfTPliez_[email protected]/ ), Sasha Levin (https://lore.kernel.org/all/aJgaiFS3aAEEd78W@lappy/ ) and Theodore Ts'o (https://lore.kernel.org/all/2025081002[email protected]/ & https://lore.kernel.org/all/2025081005[email protected]/).
-
Some highlights from various #VFS merges for #Linux 6.17 where @brauner submitted the PR:
https://git.kernel.org/torvalds/c/278c7d9b5e0ca73a75e5151c22fb05c91cb4495f: fallocate() updates bringing support for the BLK_FEAT_WRITE_ZEROES_UNMAP feature and BLK_FLAG_WRITE_ZEROES_UNMAP_DISABLED flag for SCSI, NVMe and device-mapper drivers, and add the FALLOC_FL_WRITE_ZEROES and for ext4 and raw bdev devices; this enables preventing numerous metadata changes and journal I/O, which may lead to significant write amplification and performance degradation in synchronous write mode.
https://git.kernel.org/torvalds/c/57fcb7d930d8f00f383e995aeebdcd2b416a187a: support for the the new file_getattr() and file_setattr() system calls (after lengthy discussions), which allow userspace to set filesystem inode attributes on special files (One of the usage examples is the XFS quota projects.)
https://git.kernel.org/torvalds/c/7879d7aff0ffd969fcb1a59e3f87ebb353e47b7f: ext4 IOCB_DONTCACHE support
https://git.kernel.org/torvalds/c/117eab5c6e31815649d952f6da03f67aa247d29b: An extension to the coredump socket and a proper rework of the coredump code.
-
Highlights from the main #erofs (used by #composefs) merge for #Linux 6.17[1]:
""We now support metadata compression. It can be useful for embedded use cases or archiving a large number of small files.
Additionally, readdir performance has been improved by enabling readahead (note that it was already common practice for ext3/4 non-dx and f2fs directories). We may consider further improvements later toalign with ext4's s_inode_readahead_blks behavior for slow devices too.""
[1] https://git.kernel.org/torvalds/c/76a9701325d39d8602695b19c49a9d0828c897ca
-
Highlights from the main #erofs (used by #composefs) merge for #Linux 6.17[1]:
""We now support metadata compression. It can be useful for embedded use cases or archiving a large number of small files.
Additionally, readdir performance has been improved by enabling readahead (note that it was already common practice for ext3/4 non-dx and f2fs directories). We may consider further improvements later toalign with ext4's s_inode_readahead_blks behavior for slow devices too.""
[1] https://git.kernel.org/torvalds/c/76a9701325d39d8602695b19c49a9d0828c897ca
-
Highlights from the main #erofs (used by #composefs) merge for #Linux 6.17[1]:
""We now support metadata compression. It can be useful for embedded use cases or archiving a large number of small files.
Additionally, readdir performance has been improved by enabling readahead (note that it was already common practice for ext3/4 non-dx and f2fs directories). We may consider further improvements later toalign with ext4's s_inode_readahead_blks behavior for slow devices too.""
[1] https://git.kernel.org/torvalds/c/76a9701325d39d8602695b19c49a9d0828c897ca
-
Highlights from the main #erofs (used by #composefs) merge for #Linux 6.17[1]:
""We now support metadata compression. It can be useful for embedded use cases or archiving a large number of small files.
Additionally, readdir performance has been improved by enabling readahead (note that it was already common practice for ext3/4 non-dx and f2fs directories). We may consider further improvements later toalign with ext4's s_inode_readahead_blks behavior for slow devices too.""
[1] https://git.kernel.org/torvalds/c/76a9701325d39d8602695b19c49a9d0828c897ca
-
Highlights from the main #erofs (used by #composefs) merge for #Linux 6.17[1]:
""We now support metadata compression. It can be useful for embedded use cases or archiving a large number of small files.
Additionally, readdir performance has been improved by enabling readahead (note that it was already common practice for ext3/4 non-dx and f2fs directories). We may consider further improvements later toalign with ext4's s_inode_readahead_blks behavior for slow devices too.""
[1] https://git.kernel.org/torvalds/c/76a9701325d39d8602695b19c49a9d0828c897ca
-
From the main #ntfs3 merge for #Linux 6.17[1]:
"Added:
- sanity check for file name
- mark live inode as bad and avoid any operationsFixed:
- handling of symlinks created in windows
- creation of symlinks for relative pathChanged:
- cancel setting inode as bad after removing name fails
- revert 'replace inode_trylock with inode_lock'"[1] https://git.kernel.org/torvalds/c/a11b4fa602ed3b744aa075f34bee82c12aa3553a
-
From the main #ntfs3 merge for #Linux 6.17[1]:
"Added:
- sanity check for file name
- mark live inode as bad and avoid any operationsFixed:
- handling of symlinks created in windows
- creation of symlinks for relative pathChanged:
- cancel setting inode as bad after removing name fails
- revert 'replace inode_trylock with inode_lock'"[1] https://git.kernel.org/torvalds/c/a11b4fa602ed3b744aa075f34bee82c12aa3553a