LWN on Linux 6.13 and Kernel Space Coverage
-
LWN ☛ The kernel's command-line commotion
For the most part, the 6.13 merge window has gone smoothly, with relatively few problems or disagreements — other than this one, of course. There is one other exception, though, relating to the kernel's presentation of a process's command line to interested user-space observers when a relatively new system call is used. A pull request with a simple change to make that information more user-friendly ran afoul of Linus Torvalds, who has his own view of how it should be managed.
-
LWN ☛ The beginning of the 6.13 merge window
As of this writing, just over 1,800 non-merge changesets have been pulled into the mainline kernel for the 6.13 release. That number may seem small, given that a typical merge window brings in at least 12,000 commits, but the early pulls this time around have focused on significant core changes, and there are quite a few of them. The time has come to summarize the changes pulled so far, including lazy preemption, multi-grained timestamps, new extended-attribute system calls, and more.
-
LWN ☛ The return of RWF_UNCACHED
Linux offers two broad ways of performing I/O to files. Buffered I/O, which is the usual way of accessing a file, stores a copy of the transferred data in the kernel's page cache to speed future accesses. Direct I/O, instead, moves data directly between the storage device and a user-space buffer, avoiding the page cache. Both modes have their advantages and disadvantages. In 2019, Jens Axboe proposed an uncached buffered mode to get some of the advantages of both, but that effort stalled at the time. Now, uncached buffered I/O is back with some impressive performance results behind it.
By saving data in the page cache, buffered I/O can accelerate many I/O operations. Cached data need not be reread from the storage device, and multiple write operations can be combined in the cache, reducing the number of writes back to persistent storage. But that caching comes at a cost; the page cache is typically the largest user of memory on a Linux system, and the CPU must spend time copying data to and from the cache. Direct I/O avoids this memory use and copying, but it is inherently synchronous, adds complexity to a program, and provides a number of inconvenient pitfalls, especially in cases where a file is accessed concurrently. Developers normally only reach for direct I/O if they really need it.