LWN Articles About Linux Kernel
-
Prerequisites for large anonymous folios
The work to add support for large anonymous folios to the kernel has been underway for some time, but this feature has not yet landed in the mainline. The author of this work, Ryan Roberts, has been trying to get a handle on what the remaining obstacles are so he can address them. On September 6, an online meeting of memory-management developers discussed that topic and made some progress; there is still some work to do, though, before large anonymous folios can go upstream.
Folios are, at their core, a simple mechanism to group physically contiguous pages into larger units that can be managed more efficiently. Over the last couple of years, many parts of the memory-management subsystem have been converted to use folios, but the management of anonymous pages (pages representing data that is not backed up by a file) has proved to be somewhat tricky.
-
The rest of the 6.6 merge window
Linus Torvalds released 6.6-rc1 and closed the 6.6 merge window on September 10. At that point, 12,230 non-merge changesets had been pulled into the mainline repository, which is exactly 500 more than were pulled for 6.5 at this stage in the cycle. Over 7,000 of those changes were pulled after our first-half summary was written; they brought a fair amount of new functionality with them. Read on for an overview of those changes.
-
Shrinking shrinker locking overhead
Much of the kernel's performance is dependent on caching — keeping useful information around for future use to avoid the cost of looking it up again. The kernel aggressively caches pages of file data, directory entries, inodes, slab objects, and much more. Without active measures, though, caches will tend to grow without bounds, leading to memory exhaustion. The kernel's "shrinker" mechanism exists to be that active measure, but shrinkers have some performance difficulties of their own. This patch series from Qi Zheng seeks to address one of the worst of those by removing some locking overhead.
Kernel subsystems that maintain caches should register a shrinker that can be called when the kernel needs to free memory for other uses. A shrinker is described by struct shrinker; among other things, it contains a pair of callbacks that the kernel can use to query how many cached objects could be freed, and to ask that they actually be freed. Shrinkers can be asked to focus on a specific NUMA node or memory control group, but not all shrinkers implement that functionality. Since shrinkers are called from the reclaim path when memory is tight, they should be quick and refrain from allocating memory themselves.
-
Moving physical pages from user space
Processes in a Linux system run within their own virtual address spaces. Their virtual addresses map to physical pages provided by the hardware, but the kernel takes pains to hide the physical addresses of those pages; processes normally have no way of knowing (and no need to know) where their memory is located in physical memory. As a result, the system calls for memory management also deal in virtual addresses. Gregory Price is currently trying to create an exception to this rule with a proposal for a new system call that would operate on memory using physical addresses.
-
Why glibc's fstat() is slow
The fstat() system call retrieves some of the metadata — owner, size, protections, timestamps, and so on — associated with an open file descriptor. One might not think of it as a performance-critical system call, but there are workloads that make a lot of fstat() calls; it is not something that should be slowed unnecessarily. As it turns out, though, the GNU C Library (glibc) has been doing exactly that, but a fix is in the works.