LWN.net Weekly Edition for May 21, 2026

In back-to-back sessions at the start of the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit (which spilled over into a third slot), the atomic-buffered-writes feature was discussed. In the first session, Pankaj Raghav and Andres Freund set the stage with an introduction to the problem, along with a use case for its solution: the PostgreSQL database system. In the second, Ojaswin Mujoo described a potential way forward for the feature using an approach based on writethrough, which effectively means that the kernel immediately writes the data to disk instead of waiting for writeback from the page cache to occur. As might be expected, there was quite a bit of discussion among the assembled filesystems and storage developers during the combined sessions for those tracks.

Freund began by describing what PostgreSQL currently does to prevent torn (partial) writes of its 8KB default pages; without atomic guarantees from the block layer, it uses its full-page-writes feature to write to the write-ahead log (WAL) in order to ensure that the pages are fully written. There are a number of benefits that would come with atomic 8KB writes: for example, turning off full page writes results in around 1.7x more transactions per second (TPS) with a 14x reduction in the variability of the TPS as well. It would also reduce the write amplification factor (WAF) because the pages would not need to be written twice to ensure their integrity on disk. Meanwhile, continuous archiving with point-in-time recovery requires storing the WAL in the archive logs, which can add up to a significant amount of storage quickly, he said. A simple benchmark showed a 14x increase in accumulated WAL size when full page writes is used.

An attendee asked what atomic page size PostgreSQL needed. Freund said that PostgreSQL would like to be able to write in larger chunks than 8KB, but that it only needed assurance that 8KB chunks would not be torn. Randy Jennings asked if the storage needed to be able to support these atomic writes; Freund said that it was required for the atomic-write feature.

Ted Ts'o pointed out that the "whole atomic-writes saga" has been going on for years; it has featured in multiple prior summits, for example. It started, he said, because the software-defined storage used by the cloud vendors could provide the atomic guarantees needed by databases that were using direct I/O; performance improvements of 2x were common using that feature. Now, databases that use buffered writes, like PostgreSQL, would like to get those same performance boosts, which is why the buffered-atomic-writes feature has arisen. That is especially true now that NVMe devices can provide the same atomic-write granularity as has been available for cloud storage, he said.

Raghav explained why writeback, which is used for buffered I/O, is fundamentally incompatible with atomic writes. Leaving pages in the page cache until writeback occurs provides a large window in time where the pages could be modified. Also, if there is memory pressure, page faults or reclaim could potentially result in a torn write.

So a new flag, RWF_WRITETHROUGH, has been proposed for pwritev2(), which will copy the data to the page cache and immediately issue a direct I/O to write the data from the provided buffer to the block device. Matthew Wilcox asked how the new flag differs from RWF_DSYNC; Jan Kara said that RWF_DSYNC provides a much stronger guarantee that the write operation has completed successfully all the way down to the disk. RWF_WRITETHROUGH simply indicates that the write has been issued. The RWF_WRITETHROUGH flag does not implement the atomic behavior; that would have to be added as a separate feature using the flag, Raghav said.

Christoph Hellwig said that he is not a fan of PosgreSQL's use of buffered I/O, which drives the need for buffered atomic writes, but did not have a problem with RWF_WRITETHROUGH. "I think he said 'no objection'", Amir Goldstein said to laughter.

John Garry wondered how the pwritev2() call could know for sure that the hardware can support an atomic write and determine what alignment is required to perform it. Raghav said that the plan was to use the same mechanism that is used for direct I/O (O_DIRECT) atomic writes. Ts'o said that the problem had already been solved for O_DIRECT; the alignment requirements come from the block device and using pwritev2() with the RWF_ATOMIC flag says that all of the buffers are properly aligned.

Wilcox suggested starting out small, perhaps by implementing RWF_DSYNC using the direct I/O that RWF_WRITETHROUGH does after copying the data to the page cache. But Hellwig did not think that literally using the direct-I/O path from the write made sense; simply implementing it with a regular block write might be better. The direct-I/O path handles a lot of corner cases that may not need to be considered, but he said that it was only a "gut feeling" so it was worth trying it to see. He noted that some developers have complained about the complexity of the direct-I/O code path, so maybe this effort could be a starting point for a simpler interface.

Writethrough

Next up was Mujoo, who began with a timeline of support for atomic writes in the kernel. For direct I/O, Linux 6.13 in January 2025 could write a single filesystem block atomically. In June 2025, the 6.16 kernel added the ability to handle multiple filesystem blocks atomically. On the buffered-I/O side, there have been three designs, culminating in the writethrough approach in April 2026. The first two designs suffered from the problem that there is no easy way for a given write operation to communicate with the writeback path to ensure that it is treated atomically.

As noted in the previous session, the writethrough approach avoids that problem by immediately initiating the I/O to the device from the pwritev2() call. That avoids the need to track atomic ranges for page-cache pages. Tracking those ranges made the first two designs more complex, so combining the write path with the I/O-submission path looks to simplify things. There may be other uses beyond atomic writes that can use the same technique, he said.

He stepped through a flow chart that described the writethrough mechanism. From the write, the data is copied into the page cache, a bio_vec is created from the folio range, and an I/O operation is initiated. If it is not an asynchronous write, the initial write awaits the completion of the block I/O and then returns to the caller. For an asynchronous I/O, the I/O completion is handled by a workqueue in the background, similar to the way it is done for direct I/O.

There are several use cases, he said. Buffered atomic writes can be based on writethrough without needing extra code to track atomic ranges. Writes with RWF_DSYNC can use writethrough to support asynchronous buffered writes by moving the call to generic_write_sync() from the submission to the completion phase; writethrough provides the shared context between the two phases. Likewise, other use cases that need tracking between the write and the writeback, such as RWF_DSYNC with forced unit access (FUA) and RWF_DONTCACHE writes, may be able to use writethrough.

He put up some performance graphs that showed 35-60% improvements in write speed when doing random writes to separate files from multiple threads. But they also showed up to a 65% performance decrease when all of the threads are writing to the same file. He believes that is due to contention on the inode lock, which is held within the I/O-submission path.

Ts'o wondered if that performance degradation would be a problem in practice for PostgreSQL. Freund said that there are multiple threads writing, but it is not clear to him whether there would be a lot of concurrent writing to the same file with real workloads.

Hellwig thought that the critical section holding the inode lock could be reduced, as there is no real reason to hold it throughout the I/O-submission process. Mujoo said that he could look at splitting out some of the code that currently runs with the inode lock held, which Hellwig thought should be doable and might help simplify some other code paths.

There was some discussion of the need to prevent writeback occurring on the pages in the page cache while the writethrough operation is being performed. There is a need to prevent modification of the in-flight buffer, which could interfere with checksums and the like, Hellwig said; that can be accomplished by taking the writeback lock. The default mode for the iomap layer is to submit its I/O without holding the page lock, just the writeback lock, he said.

The discussion turned to reducing contention on the xa_lock and possibly using a shared lock for aligned, buffered I/O, as is used for direct I/O. Kara seemed to think it was a reasonable idea and Hellwig suggested that the right time to introduce such a lock was when a new flag (e.g. RWF_WRITETHROUGH) was being added. The proposed writethrough feature is much the same as RWF_DSYNC, Hellwig said, except that it does not guarantee that the block device actually flushes its cache to disk. If a shared lock is added later, a new flag will need to be added at that time to govern its use, so it makes sense to just include that with the writethrough feature in his mind.

io_uring

Josef Bacik said that he hated having this kind of conversation and wanted to step back and look toward avoiding all of the various special cases in the I/O path that are handled by adding new flags. "What we should be doing here is just rethinking how we do this"; he suggested looking at io_uring as a potential solution. Each of the low-level operations needed for I/O (update the page cache, submit the I/O operation, etc.) would be a separate io_uring operation that can be built up into whatever style of I/O user space wants.

Doing so would allow user space to "mix and match all of these different features" and avoid needing the kernel developers to figure out how new pwritev2() flags interact for all of the different special cases. Christian Brauner was concerned that the same problems would eventually arise for an io_uring-based solution; in a few years, there would need to be discussions about how the different operations interact. Hellwig did not see why moving the problem into io_uring would make the situation any better, though he found Bacik's description to be fairly abstract.

Goldstein worried that it would be difficult for users to understand how to use the io_uring interface; meanwhile, the flags are a way to limit the number of different ways the operations can be combined, so moving to io_uring would substantially increase the testing matrix required. Bacik said that every new use case brings a slight wrinkle to how the write operation interacts with the page cache, writeback, iomap, and so on; of the full matrix that might be exposed, the flags limit the choices, but that ends up leading to more flags.

I/O testing already "sucks" and moving to io_uring would potentially make that worse, he said. But "it pushes the complexity of what user space wants down to user space", which is better than cementing various heuristics and policy decisions into the kernel code. That results in user-space developers being unhappy because their specific use case is not one of the ones supported—followed by another flag proposal and long discussions on the mailing list and at the summit.

Ts'o said that they would need to see the code before being able to determine whether the approach was viable, but his concern was that locks would need to be taken multiple times for the various sub-operations. There might be a way to analyze the series of operations in order to optimize the locking, but without that, performance may suffer compared to what there is today. Analyzing the operations and combining the lock acquisition would also increase the test matrix because it would make things dependent on the order of operations "and this scares me".

Hellwig wondered what concrete io_uring operations were being talked about, as he still found the discussion to be too abstract. Brauner asked: "Why is Jens [Axboe] so silent?". That was met with laughter and, eventually, a response from Axboe, who is the io_uring maintainer, but it was clear that he did not have strong feelings about the idea. Bacik said that it simply did not make sense to "add a new flag every two years" to do some "new, special thing".

The complexity of the new io_uring commands led to worries that most developers would not be able to use them; there is a reason that the kernel developers are defining how the different kinds of I/O should be done. Bacik said that the synchronous-I/O options could continue being handled with flags of various sorts, but that newer, fancier asynchronous use cases could be pointed at the io_uring-based approach.

Hellwig was somewhat skeptical that the various operations could be fully defined with their semantics clearly specified, but even then the testing becomes burdensome. Others were not so sure that it would change the testing picture all that much in comparison to all of the existing flags and combinations of them. Brauner worried that changes to the semantics of writes would continue and that in five years, say, the same kinds of discussions would have to happen for an io_uring-based solution; it may just be kicking the can down the road.

After Axboe pointed out that system calls could be added instead, Bacik wondered, perhaps not entirely seriously, if instead of io_uring he should have proposed "17 new syscalls"; he simply thought that io_uring "sounded better". He is concerned that trying to shoehorn all of a feature under a single all-encompassing flag leads to problems; finding a way to split up the pieces that are composed to perform the I/O would make more sense.

There was some discussion of the overall design of the I/O API that currently exists versus what might be done differently if the kernel developers were to start over. For example, Ts'o noted that O_DIRECT was designed by Oracle several decades ago and filesystems implement it differently because it was not clearly specified. But any overhaul of the API will not be used widely for multiple years and, meanwhile, the current API will have to be maintained.

Goldstein summarized that part of the discussion as the session concluded by saying that adding a new flag is probably the easier approach because user-space developers are used to the system-call API and understand it. But the flag should be well-documented first, so that reviewers can try to ensure that it makes sense and fits with everything else. If it cannot be clearly specified, that is a pretty clear indication that the feature is not on the right track.

[I would like to apologize for any errors here. The acoustics in the room were problematic for both hearing and recording. Misunderstanding and misidentification may have resulted.]

Keeping COWs in context (a.k.a. anonymous reverse mapping)

By Jonathan Corbet
May 14, 2026

The kernel's reverse-mapping machinery is charged with locating the page-table entries that refer to a given page in memory. The reverse mapping of anonymous pages is handled differently than for file-backed pages. The kernel's implementation of reverse mapping for anonymous pages is, according to Lorenzo Stoakes in his proposal for a memory-management-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, "a very broken abstraction", due to its complexity. It also has some performance problems. Stoakes was there to present, in raw form, a proposed replacement that he calls a "COW context".

The system's page tables map a virtual address to the physical page (if any) the address points to. There is no hardware mechanism, though, to go in the other direction — from a physical page to the page-table entries that refer to it. This reverse mapping is needed by the kernel, though, in order to manage memory. Many years ago, reverse mapping of anonymous pages was done by scanning through all of the page tables in the system; needless to say, that was not the fastest possible solution. Rik van Riel added a reverse-mapping mechanism to eliminate the page-table scans in 2002; that machinery was significantly reworked by Andrea Arcangeli two years later. The code has evolved considerably in the subsequent two decades, generally in the direction of more complexity. The portion dedicated to the reverse-mapping of anonymous pages is particularly difficult to follow.

Stoakes began by complaining about that complexity, saying that the code is, in many places, inscrutable. He also lamented the fact that the reverse-mapping code holds locks across an entire fork operation, creating high lock contention and the consequent scalability problems. There are a vast number of kernel objects used to provide reverse mappings, which creates a lot of memory overhead.

He has been working on an alternative, which can be found (in first-draft form) in this repository branch. The current reverse-mapping code works at the virtual memory area (VMA) level; since a single process can have large numbers of VMAs, that is a lot of tracking to do. Stoakes is, instead, proposing a "COW context" that is used to track anonymous mappings at the mm_struct level. There is one mm_struct structure per process; it is the core data structure describing a process's address space. Since only one COW context is needed per process, the system must maintain far fewer of them than if it were a per-VMA structure.

While the COW context is associated with the mm_struct, it is managed as a separate structure. Why is the COW context not directly incorporated into struct mm_struct? The COW context structures are linked together to represent the process hierarchy, but they may have to outlive their associated processes. If a process creates a number of children, then exits, its COW context must still exist to maintain the kernel's model of the series of forks that brought about the still-existing processes, since they are likely to continue to share mappings to anonymous pages.

Each page (strictly, each folio; see this article for a discussion of the difference) gains a pointer to the COW context of the process that first maps it. When the time comes to find all of the mappings of that folio, that pointer can be followed, yielding the COW context at the top of the hierarchy of processes that may have mappings; at that point, it is just a matter of walking the tree of COW contexts to find any other mappings that may exist. There are, of course, complications, many of which tied to the fact that processes can remap their address spaces, meaning that a folio may be mapped at different virtual addresses in different processes. Tracking those remappings adds a fair amount of complexity to the patch set. Stoakes also noted that files mapped with MAP_PRIVATE bring pain of their own.

If a process has created a lot of children, there could be a lot of COW contexts to walk through. To optimize that walk, effort is made to link folios to the COW context at the lowest part of the hierarchy in which they are mapped. As a result, reverse-mapping lookups are quick most of the time.

One advantage of the new structure is that the lookups can be done under read-copy-update (RCU) protection rather than locking. That is both good and bad; RCU is much faster, but it lacks the synchronization points that locking brings. So he is going to have to introduce some sort of lock with mapping granularity. A "crazier" alternative would be to simply tolerate races to an extent; that would require delaying the freeing of page tables until after an RCU grace period, though.

Stoakes concluded his presentation as the session ran out of time; there was no real discussion resulting from the talk. He acknowledged that the code, as it exists now, has a lot of rough edges and incomplete parts. It is, he said, a research project that might not work out in the end. But, if nothing else, he will have learned a lot more about anonymous reverse mapping.

Policy groups for memory management

By Jonathan Corbet
May 14, 2026

The kernel's control-group subsystem works well for resource management, Chris Li said at the beginning of his memory-management-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit. Control groups work less well for other use cases, though. He was there to present his proposed enhancement, called "policy groups", that would address some of the shortcomings that he has encountered. A consensus on how this feature should look still seems distant, though.

Resource management is designed deeply into control groups; this focus drives a core assumption that the resources granted to a parent group must be greater than or equal to the resources given to any of its child groups. Control groups are also organized into a unified hierarchy; that was a key requirement of the control-group redesign effort over a decade ago. But this design has limitations; it does not fit cases that do not conform to its resource-management model, the unified hierarchy does not work for all use cases, and control groups are not an effective tool for policies that are not tied to processes.

As an example of a policy that doesn't fit the resource model, he said, consider service-level objectives. A child group might be given a service level that is either faster or slower than its parent. An area of particular interest to Li is regulating access to swap devices of different speeds; the difficulty in adapting control groups to this model is impeding the upstreaming of the swap-tiers work. A case that doesn't fit the unified hierarchy would be the Android distinction between foreground and background tasks; applications can perform some of that organization internally, but what they come up with may not fit the system's view of the process hierarchy. Non-process cases include control over filesystem allocation and network-control policies.

The proposed policy groups, which would be attached to control groups in an unspecified way, would address these limitations. Policy groups would be focused on managing policies rather than resources and would not be forced into the same hierarchical model. There have been other attempts at this sort of control, he said, including network namespaces, NUMA memory policies, and the use of prctl() to control behaviors like kernel samepage merging. Policy groups would bring a more formalized structure to this kind of feature.

Liam Howlett said that policy-related features typically use prctl(), and asked whether that is really a good fit for this task. There are, he suggested, a lot of features stuffed into prctl() that should perhaps be implemented differently. Suren Baghdasaryan asked why policy groups would be associated with control groups if the policies to be enforced are not hierarchical in nature; Li answered that there is still a need to attach policies to the process hierarchy.

Lennart Poettering said that the control-group redesign moved that subsystem away from independent hierarchies, which was a good thing; it would be better to avoid bringing that concept back. In more recent kernels, it is possible to attach extended attributes to control groups; these, he suggested, could be used to attach policies. The BPF Linux security module uses extended attributes attached to control groups in this way. Extended attributes, he said, might well be a good fit for policy groups as well. Li answered that this approach might work for some cases, but not for those that are not inherently tied to processes.

Roman Gushchin said that policy groups probably should not be attached to control groups at all. Another participant said that grouping all these policies under a single framework might be a mistake. It could be better, he said, to attach some policies to a filesystem, and others to a control group, for example. While an overall policy framework might be useful, nobody has ever figured out a generally applicable solution.

Li asked whether the right approach might be to create a new policy-group virtual filesystem; it might present a flat view rather than implementing a hierarchy. Poettering answered that he is not looking forward to dealing with yet another control interface from the kernel. Li asked how Poettering would suggest setting a process's service level for swap; Poettering repeated the extended-attributes idea.

The discussion lost focus as time ran out; a suggestion to add a new namespace type did not get a lot of support. It was seemingly agreed that it would be better to not add a new control structure if possible. Using BPF was suggested, but there are systems (especially in the embedded area) that do not support BPF, so Li said he would prefer to avoid that approach. The session closed with Li saying that he would look more closely at ways of attaching policies directly to processes.

HugeTLB preservation over live update

By Jonathan Corbet
May 15, 2026

Recent times have seen a lot of effort put into the implementation of the kexec handover and live update orchestrator features in the Linux kernel. But that work is not yet complete. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Pratyush Yadav led a memory-management-track session on adding the ability to preserve hugetlbfs-provided memory during the live-update process.

The use case for live updates, Yadav began, is to replace the host kernel on a running system without disturbing the virtual machines running under that kernel. The kexec handover machinery marks regions of memory to be preserved during the kernel change; it is an in-kernel interface with no user-space API. Once memory has been marked, the kexec_load() system call is invoked to boot the new kernel, after which the preserved memory is restored to its owning process. The live update orchestrator provides the user-space interface to this feature, letting users mark resources to preserve and restore them on the new kernel.

Kexec handover and the live update orchestrator were merged during the 6.19 development cycle, with limited support for the preservation of files in memory-based filesystems. It can handle memfds (anonymous files created with memfd_create()) backed by shared memory, but not much else. That feature can be used to preserve the contents of a virtual machine, but running virtual machines in memfds is relatively inefficient. A virtual machine placed in a small number of huge pages (perhaps of the 1GB variety) from the hugetlbfs subsystem will run more efficiently, but that memory will not, yet, survive a live update.

Yadav's goals are to make it possible to carry those virtual machines (and their associated memory) through the live-update process. Preferably, it would be possible to obtain hugetlbfs pages by way of a special memfd, so that mounting hugetlbfs itself would not be necessary. The intent is to minimize the amount of preserved state; everything that is preserved becomes a part of the kernel's ABI, so less of it is better. He is also working to minimize the number of changes to hugetlbfs itself.

The feature works by first freezing the contents of the huge pages to be preserved, so that changes are not lost during the update process. There are two ways of doing that; the first would be to add a flag to the associated hugetlbfs inodes, then check that flag when changes are about to be made. The shared-memory filesystem works this way. In addition, the relevant memory would be pinned to prevent migration or compaction during the update. This option can work, but it is seen as a bit of a hack by some developers. The alternative is to make the filemap code aware of freezing by way of a new address-space flag; once again, the flag would be checked before allowing modifications. There are various details that have to be managed to make this option work correctly, meaning that the virtual filesystem layer has to be aware of the freezing process.

After the pages are frozen, some metadata about each — its size and position — is recorded. Both the frozen pages and the metadata are marked for preservation. Then the update can proceed.

Once the new kernel is running, a new hugetlbfs-backed memfd is created, and each of its component huge pages is placed back into use, with the hugetlbfs state being updated accordingly. Control-group charging for the allocated memory is done, and the new pages are added to the page cache. At that point, from the point of view of memory preservation, the update process is complete.

There is a bit of a complication regarding huge-page allocation, Yadav said. Hugetlbfs works by preallocating a set number of huge pages during the boot process. The restoration of a hugetlbfs-backed virtual machine will also allocate the necessary huge pages. In the original kernel, those pages were allocated from hugetlbfs; in the new kernel, instead, they are allocated separately. That can lead to over-allocation of huge pages in general. The solution is to count the number of preserved huge pages when the new kernel is booting, then to reduce the number preallocated by hugetlbfs accordingly.

An as-yet unsolved problem is the interaction of this feature with the contiguous memory allocator (CMA). If the original huge pages were obtained from CMA, the new pages need to be inserted back into CMA after the update, but CMA does not offer any way of extending its memory zone. So the current patches just disable the use of hugetlbfs with CMA if live update is enabled. Someday it will be possible to preserve the state of CMA as well, but that does not happen with the current version of this work.

Yadav closed with a status summary, saying that an RFC patch set had been posted in December 2025. As part of that work, he had found a number of problems with kexec handover that required some significant infrastructure work to fix. He will soon be posting an updated patch set, once he has responded to the feedback he has received.

The only question came from Mike Rapoport, who wondered if making CMA pages movable would help in its integration with kexec handover. Yadav said that such a change had a high chance of breaking things and probably would not help much.

Controlling memory management with BPF

By Jonathan Corbet
May 15, 2026

Roman Gushchin began his session in the memory-management track of the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit by saying that the community has seen a lot of proposals adding BPF-based interfaces for memory management. None of them have made their way into the mainline, though. He wanted to explore the ways in which BPF might be helpful and the obstacles that have kept BPF-based solutions out so far. This session was followed by a discussion led by Shakeel Butt on what the requirements for a new, BPF-based interface for memory control groups might look like.

Obstacles to BPF integration

Existing efforts have tried to capture a number of different memory-management heuristics, he began. There have been proposals to use BPF to control out-of-memory handling, NUMA balancing, memory control groups, page-cache eviction, and more. There are more interesting ideas that have not yet been pursued, including readahead control, madvise(), kernel samepage merging, and guest-memory control. Readahead, in particular, is a messy set of heuristics, but it is important for performance.

There are a number of obstacles to the addition of BPF interfaces for the memory-management subsystem, he said; he would cover them from the least important to the most. The first was concerns about out-of-tree BPF programs. Kernel developers want to see production-quality code land in the mainline, but that is not how BPF is working now. There are production-quality sched_ext schedulers, for example, but they are all stubbornly out of tree. BPF maintainer Alexei Starovoitov said that "sched_ext was a mistake", in that it did not bring any production schedulers with it into the mainline. That is a hard situation to fix now, he said. It would be good to have a good, in-tree out-of-memory handler; if nothing else, it would help developers to judge the proposed interfaces.

Including BPF programs in the kernel tree does not seem to be controversial, Gushchin said, so the real question is how far developers should go. A first step would be to just include the source for people to examine and play with. Automatic loading of included BPF programs could be a good second step, Starovoitov said; it would let people use the included BPF programs easily. Gushchin suggested that a BPF implementation of systemd-oomd would provide a good example of how that subsystem works.

Another obstacle is the current inability to attach struct ops programs to control groups. BPF programs can be attached, but not those using the struct ops interface. He has an implementation for the out-of-memory handler, but sched_ext uses a different solution.

Then, there is the issue of safety and fallback; a broken BPF memory-management program could easily make the system unusable. This is the hardest issue to solve, at least from Gushchin's perspective; it is hard even to define what "safety" means in this context. Time-based fallbacks are hard to implement and ugly, he said. Memory-management actions can be wrapped into monitored kfuncs, but that leads to non-generic solutions that can hurt performance. The acceptable level of service needs to be defined; a traffic-control program that drops all packets is OK, but a sched_ext scheduler that starves half of the tasks in the system is less so. What should happen if a faulty BPF program is loaded and the system can no longer reclaim memory?

There will always be concerns about performance in hot paths, which will make it hard to justify adding BPF programs in the hottest of them. The memory-management subsystem depends heavily on batching for performance, raising the question of whether BPF programs should run before or after batching is done. He suggested that batching should happen first, but that makes it impossible to control the batching itself with a BPF program.

Finally, the most important obstacle, he said, is ABI stability; this concern had been most recently raised by David Hildenbrand on the mailing list. In person, Hildenbrand said that there was some confusion about what providing hooks for BPF programs means; are they a permanent memory-management feature? The community may not want to commit to keeping those hooks around indefinitely. That concern has led to a decision not to provide hooks for the management of transparent huge pages; nobody knows what the picture will look like in five years, he said, so it will not be possible to get the interface right.

What will happen, he said, is that memory-management developers will wake up someday and realize that some aspect of the interface should be done differently. If they act on that realization, programs will break and people will get angry. Perhaps the solution is to only commit to supporting BPF programs that are maintained in the kernel tree itself. Hildenbrand concluded by saying that he sees the value of using BPF, but worries that adding interfaces may commit the subsystem to maintaining features that it regrets in the future.

The session was out of time at this point. At the conclusion, Gushchin said that it would be important to add only the most generic sorts of BPF hooks. So, for example, a hook to assign out-of-memory scores would be a bad idea, since a future out-of-memory killer might not use them. But a hook to free some memory under pressure, perhaps by killing some processes, could be useful.

Reimagining memory control groups

Butt followed immediately after with a discussion of how he might like to see the kernel's memory controller evolve, and how BPF might fit into that. He started by saying that the memory controller distributes memory resources hierarchically, implementing both hard and soft limits. Any given group will be allowed to use up to its hard limit when memory is plentiful, but will be squeezed back to the soft limit when memory is tight.

The memory controller has a number of challenges, he said. The enforcement of limits is inflexible and disruptive; since it happens synchronously, it can cause unexpected stalls in latency-sensitive threads. Its interfaces have proved hard to evolve, since significant changes will break the existing ABI, which kernel developers are not allowed to do. It would be nice, he said, to have a mechanism that would make it possible to experiment with alternatives.

The goal of a new interface would be to provide capabilities to support a wide variety of use cases. One example use case was provided in his session proposal and repeated during the session itself:

Policy: "keep system-level memory utilization below 95 percent; avoid priority inversions by not throttling allocators holding locks; trim each workload's usage to its working set without regressing its relevant performance metrics; collaborate with workloads on load shedding and memory trimming decisions; and under extreme memory pressure, collaborate with the OOM killer and the central job scheduler to kill and clean up a workload."

A new memory controller, he said, would need to provide memory-use notifications that applications can act on. It needs to support background reclaim, so that memory limits can be enforced without stalling running threads. Memory-use throttling should be aware of threads that hold locks to avoid priority-inversion problems. User space needs to be able to influence throttling in other ways, with the ability to, for example, identify specific threads that should be exempt to an extent. The controller should also support memory tiering, providing control over how pages are moved between tiers.

There was not much time to go into how this new interface would work; this effort, in general, appears to be in an early stage. Butt said that a new BPF callback, bpf_memcg_charge_succeed(), could be added to inform a BPF program about an increase in memory usage; that program might then respond by initiating background reclaim. Other callbacks could inform the program when a control group has reached a usage watermark (or hit a usage limit), relying on the program to provide hints on how to respond. That program might initiate some sort of reclaim, but it could also inform the application of the situation with the expectation that said application would respond by reducing its memory usage.

At the end, a member of the audience said that a useful feature would be the ability to introspect what types of memory an application is using; Butt answered that this feature was already being worked on.

Swap tables, flash-friendly swap, swap_ops, and more

By Jonathan Corbet
May 18, 2026

The kernel's swap subsystem is charged with managing anonymous pages in secondary storage when those pages are (hopefully) not being used and the memory they occupy is needed elsewhere. This long-unloved subsystem has seen a resurgence of developer interest in recent times, so it is not surprising that it was the topic of three separate sessions in the memory-management track at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit. Two of those sessions were concerned with improving the performance and maintainability of the swap code, while one (shared with the storage track) was about how swapping could be friendlier to solid-state storage devices.

Status and roadmap

The first session was a breakneck-paced presentation from Kairui Song on recent changes in the swap subsystem and what is coming next. Song began by describing his work introducing the swap table and removing a lot of swap-subsystem complexity; see this article and its successor for details on this work. Before his changes were merged for 7.0, the swap subsystem incurred an overhead of between three and 11 bytes per page; that overhead is now reduced to between two and ten bytes. That news was greeted by applause in the room.

Song is not done, though; he intends to cut the static overhead to zero bytes, albeit still with a maximum of ten. His goal to cap that overhead at eight bytes will not be realized in the short term because refault tracking for the memory resource controller requires more data. In the long term, he still hopes to cut the maximum overhead to three bytes per page.

The need for some operations to bypass the swap cache has been removed, and most of the swap-oriented helpers are now folio based. Most operations only need the folio lock now; there are opportunities, he said, to optimize further by applying some lockless algorithms. Work to unify folio allocation with the swap cache is still in progress. Currently, anonymous and shared-memory folios come with their own allocation logic that may bypass readahead; he described this code as a long, complex, and racy fallback loop. He is working to replace it with a single allocation helper.

Other work is aimed at letting the system make better use of the swap cache; better readahead support is an important step in that direction. The zram subsystem can take advantage of it now but, he said, whether that is beneficial is not entirely clear. It may be that zram is fast enough already.

Swapping I/O is asynchronous and takes time; that means that there can be a long delay between the onset of memory pressure and the completion of the I/O that allows that pressure to be relieved. By the time that happens, it may turn out that the system has overshot and swapped out more pages than really needed. This could be helped by immediately dropping pages from the swap cache once writeout has completed. He is not sure why that is not always done now; more research is needed there.

There are a number of other problems yet to be solved. Swapping of PMD-level huge pages is not as efficient as it could be. Readahead can end up bringing in pages used for hibernation, which is wasteful but not a huge problem, though the workaround is ugly. He is contemplating adding a special bit to mark pages reserved for hibernation. There are users who would like to be able to resize swap areas on the fly; that should be practical to implement now.

Another problem arises when both anonymous and shared-memory (shmfs) folios are swapped to the same device. If shmfs-backed transparent huge pages (THPs) are being swapped, they can end up overlapping an anonymous page's slot; when that happens now, the offending folio is simply dropped. The problem will worsen, though, if readahead gains support for THPs. He is contemplating creating a new swap-table type to address this problem. Matthew Wilcox said the problem may come down to a confusion of logical (within the owning process's address space) and physical readahead; we are doing something wrong somewhere, he suggested.

Song is looking into compaction of the swap table. The system manages swap space in clusters, which are organized into a least-recently-used list. It might be possible to drop full clusters from the list; that would increase performance, but might increase memory pressure.

All of the above was compressed into a half-hour slot, but Song was not done yet. The time is coming, he said, where swap files should be renamed to "swap mappings". Swapping now looks a lot like the mapping used for file-backed memory, though with different writeback policies and locking schemes. Much of this could be abstracted out by adding a new virtual swap layer, which could address a number of other problems (such as defragmentation and migration) as well. He put up a slide showing the overall design of this layer:

An RFC patch set has been posted with an initial implementation of this idea. It reuses the existing swap infrastructure, but adds an extra layer of mapping. Among other things, this design allows for faster removal of a swap device (since there is no longer a need to adjust the page-table entries for all of the processes that have pages on the to-be-removed device) and easy defragmentation of swap devices.

Johannes Weiner pointed out that this design could make it easier to swap out huge pages without requiring large chunks of contiguous space on the swap device. David Hildenbrand asked how large the virtual table would be, and whether it might suffer from fragmentation; Song answered that the table can be made large enough to avoid that problem.

Flash-friendly swapping

Swapping can generate a lot of I/O that, if not managed properly, can significantly shorten the lifetime of solid-state storage devices. Youngjun Park is working with embedded devices that make aggressive use of swap, and he would like those devices to not burn out their swap storage prematurely. This session was held jointly between the memory-management and storage tracks.

Flash storage, he said, will wear out over time. Rewriting of data will cause erase cycles, so copying data to the device will cause extra writes and extra wear. The built-in flash translation layer (FTL) has some support for wear leveling, but it is not enough, with the result that swapping is hard on flash devices. It creates a steady stream of random 4KB operations that challenge the wear-leveling algorithms, but flash-friendly write patterns do exist and can be made use of.

The embedded device in question swaps to RAM using a custom mechanism, similar to zram, that compresses pages in memory. These pages are flushed to persistent storage by a kernel thread that is registered as a shrinker; it performs sequential writes that are aligned to erase blocks. There is a deduplication layer that reduces write operations; in particular, there are a lot of matches with pages that were saved in previous hibernation rounds and do not need to be rewritten. The result, he said, is a big increase in the lifetime of the storage device.

Christoph Hellwig asked Park to share his code, "even if it's ugly"; that would help others to understand what is going on. Park answered that it is a implemented as a block device and hard to upstream; Hellwig said that the point was not to merge the code, but to push the discussion forward. There are some good ideas there, he said; the code would likely need a major restructuring, but it helps to have a working starting point.

Weiner asked if Park had looked at using zswap with some sort of writeback added on. The answer was that this option had been considered but (for unspecified reasons) not used. Wilcox said that he found the described approach surprising, that overwriting full erase blocks tends to work better. Chris Li commented that it is hard to discover the parameters that describe the optimal I/O patterns for a given device, and that he would like to encourage vendors to be more free with that information.

The final part of the session was focused on the fact that Park's system depends heavily on hibernation, which is the source of much of the swap traffic. Perhaps, it was suggested, it might be better to decouple swap and hibernation and make it possible to create a separate hibernation target that would still use the swap device, but would avoid the swap code and its I/O patterns.

Abstracting the swap backend

The swap subsystem was designed to interface directly with a block device, and it creates its block-I/O operations internally. There is interest, though, in the ability to put other types of devices at the storage layer of the swap subsystem. This concept, which goes by the name "swap_ops", was proposed for discussion by Baoquan He, but, as Li explained in the session, He had fallen victim to Red Hat's closure of its entire China-based development operation, so Li would be running the discussion instead.

The core idea behind swap_ops, he began, is that it would be a subsystem to enable modular swap backends and allow the customization of some swap behavior. It would be a virtual filesystem (VFS) layer for swap, he said. The idea was first proposed at the 2023 LSFMM+BPF gathering, and further discussed in 2024 and 2025. There are a number of similarities with the VFS; where the VFS has a superblock at the beginning of a filesystem, for example, the swap layer has its swap header. A file in the VFS is much like a folio in the swap subsystem, an inode is similar to a swap entry, and so on. But the swap_ops layer would have a much lower overhead, and would not support an equivalent to directories.

There is, Li said, a patch series implementing this concept; He updated the series on May 12. As an example of its value, Li pointed out that the zram subsystem is currently emulating a block device; it would be possible to remove a lot of code if zram were implemented as a swap_ops backend. Other possible backends could be a flash-friendly layer as Park had described, or even one that works with raw flash, though the room was not receptive to that idea. Eventually support for compressed page I/O could be added as well.

At the end, Li said that it might make sense to allow the backend to handle the allocation of swap slots. There is also work to be done to figure out the best way to move pages between backends. Li concluded there, and there were no questions from the group.

Improving the per-CPU memory allocator

By Jonathan Corbet
May 19, 2026

There are many places in the kernel where performance can be improved by using per-CPU data. But, as it turns out, the kernel's allocator for per-CPU data has some performance problems of its own. Harry Yoo led a session in the memory-management track of the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit to explore ways to address those problems and accelerate the allocation and initialization of per-CPU data.

The dynamic per-CPU allocator was added by Tejun Heo for the 2.6.30 kernel release in 2009; it is built on a per-CPU-data infrastructure whose origin is lost in pre-Git antiquity. Documentation for users of this API is, presumably, in the works and will hopefully show up soon. Allocation of a per-CPU area results in an array of objects, indexed by CPU number, where each CPU's memory lives in a different cache line to avoid contention. A common use for this data is the creation of statistics counters. Each CPU can quickly increment its own counter as needed; when a total is required, it can be obtained by calculating a sum of all the per-CPU values.

This being a gathering of memory-management developers, there was particular interest in the per-CPU counters (rss_stat, stored in each process's mm_struct structure) used to keep track of each process's resident set size (RSS). Allocation and freeing of memory is a frequent operation, so managing a process-global RSS counter would be expensive for highly threaded processes. Splitting those counters into a per-CPU array can avoid contention on a global counter but, as was discussed in this session, can lead to other performance problems.

Yoo began by saying that there are two specific shortcomings with the current per-CPU allocator. One is that it was not designed for scalability; it uses a global lock for the allocation and freeing of memory. It is not uncommon to see multiple CPUs allocating per-CPU memory concurrently, leading to contention on that lock. The other problem is that initializing the per-CPU array can be expensive, especially in cases where there are a lot of CPUs and the data itself is short-lived. There have been a number of proposed solutions, he said, with the result that there are too many ideas floating around but not enough actual progress.

One of those ideas, he said, was dual-mode per-CPU counters, an idea that was proposed by Gabriel Krisman Bertazi as a solution to performance problems associated with the RSS counters. Under this proposal, when a set of counters is allocated for a new process, it will be created in a single-threaded mode, since the process itself only has one thread at that point. That greatly reduces the initialization cost. Should the process create a new thread sharing the same address space, the counters are upgraded into the full per-CPU mode. Since many processes never do create threads, this proposal eliminates the initialization cost entirely much of the time.

An alternative, shown in this series from Yoo, integrates the per-CPU allocator more closely with the slab allocator, and restores the slab destructor operation, which was removed many years ago. That would allow per-CPU objects to be retained in the slab cache and, in particular, would only require the constructor to be called on the initial allocation. This scheme would only work if users of per-CPU objects leave them in a reasonable state when freeing them. Some care would have to be taken with this approach, Yoo said, to limit lock acquisition in destructors to avoid deadlocks.

Finally, Mathieu Desnoyers (who attended the session via remote link) has proposed using the "per-MM concurrency IDs" (or "mm_cids") for this task. An mm_cid is a virtual CPU ID that is maintained as part of the restartable-sequences subsystem. Unlike a real CPU number, which can be as large as the number of CPUs the system might conceivably support, the mm_cid is bounded by both the number of threads the running process has and the number of CPUs that process is allowed to run on. As a result, it will generally be a much smaller number. A process with four threads on a 256-CPU system might see a CPU number as high as 255, but its maximum mm_cid will be three. See this article and the rseq() manual page for more details on this feature.

The core of Desnoyers's proposal, as he described it in the session, is that per-CPU data could be indexed using the mm_cid rather than the actual CPU ID. That would still isolate each CPU's access to the array, but the array itself could be much smaller. Individual entries would be initialized on first use, keeping the initialization cost down.

Kiryl Shutsemau pointed out that get_user_pages_remote() can allocate pages on a CPU other than the one it is running on, and Shakeel Butt wondered about remote access to another CPU's counters in general. Shutsemau also raised other cases of remote access, such as when a process is being manipulated with ptrace(). In those cases, the code in question is not part of the process it is manipulating, so the mm_cids will not match. Desnoyers said that would be an uncommon case that might be best addressed by adding a separate counter.

Yoo pushed for a conclusion, saying that some sort of solution was needed in the mainline. Davidlohr Bueso indicated support for the mm_cid idea, asking what problems would prevent it from being adopted. Shutsemau raised the get_user_pages_remote() problem again, but said that he would have to look more closely to determine if it is really a problem or not. Suren Baghdasaryan wondered how much extra overhead the mm_cid solution would add in general.

Another participant pointed out that the RSS counters are known to be imprecise, and that Desnoyers has been circulating a patch series to improve them. Some of the proposed solutions to the per-CPU problem are specific to the RSS counter format, he said, suggesting that the mm_cid solution is more general and would be preferable.

Yoo brought the session to a close by asking, again, what the conclusion should be; the room seemed to be heading toward a consensus to take the mm_cid approach. Butt suggested that Desnoyers should send patches implementing that solution; Desnoyers said that the idea only existed in his head for now, so it would take some time to put together a proper patch set.

Comments (2 posted)

What's brewing in CXL

By Jonathan Corbet
May 19, 2026

Compute Express Link (CXL) is a technology intended to enable the provision of "memory nodes" in data centers that provide (possibly shared) memory to nearby CPUs. It has, Dan Williams said at the beginning of his memory-management-track session on the topic at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, "been making memory-management problems worse since 2021". He used the session to provide an overview of the ways in which CXL can be expected to extend that record into the future.

CXL, he began, is a way of providing memory over the PCIe bus; it generally offers latency that is worse than accessing memory on remote NUMA nodes. The strength and challenge of CXL is that it is highly configurable, allowing, for example, the setup of interleaved memory access that improves performance. One problem is that, while the kernel can control some access to CXL memory, the system firmware wants to play with things as well. Another challenge comes with the hot-plug nature of CXL memory; if it goes away, a portion of the system's RAM can disappear.

The CXL standard is evolving quickly, and manufacturers are putting out hardware with interesting deviations from the adopted standards. The kernel is following something like the ACPI "code-first" policy with regard to these changes and documenting them in the kernel tree. The hope is to send a message to manufacturers: "somebody broke it this way, please break yours the same way".

Error handling is an evolving area as well. CXL protocol errors are reported to the kernel as PCIe internal errors, but they are handled through a side channel so that the PCIe core code does not need to deal with them. The CXL code is introducing kernel panics in its error-handling paths; that is not something that is normally appreciated in kernel code but, Williams said, the firmware is going to panic the system anyway in such situations.

Accelerator support (memory-to-memory compression, for example) is close to landing in the kernel. It turns out that accelerators are relatively simple to support. Another development area is vfio-cxl, which is a mechanism to allow exporting CXL accelerators to virtual machines.

Dynamic capacity has long been a dream for system designers, Williams said. One buys a lot of DIMMs, puts them into a box, runs a cable, and a lot of hosts can then map that memory. But then the kernel has to somehow make that memory available to user space. The plan is to use device DAX as the interface, but there are questions about how to create private nodes for dedicated memory (a topic that would return the following day). There needs to be integration with guest_memfd as well.

What is not brewing in CXL support? One non-development area is error isolation; if a CXL host bridge is lost, all associated devices will fail, and terabytes of system RAM may vanish. It is hard to envision a way in which the system can survive such an event, at least when memory is involved. Error isolation for accelerator users might be more feasible. There is also no work currently on supporting peer-to-peer operations on CXL devices, but "somebody will want it someday". Finally, CXL encryption, which he described as "another bucket of acronyms", is also not expected to be supported in the near future.

The session concluded there, with no real discussion among those present.

What is to be done about MGLRU?

By Jonathan Corbet
May 20, 2026

"Reclaim" is the task of finding memory that can be taken away from its current user and put to better uses within the system; it is a core part of the memory-management picture. The addition of the multi-generational LRU (MGLRU) was meant to provide a better reclaim implementation than the "traditional LRU" that preceded it, but MGLRU has complicated the situation instead. No fewer than three memory-management-track sessions at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit were focused on MGLRU, with an eye toward integrating it more fully, improving its performance, and addressing some problems encountered with Android systems.

Unifying the reclaim code

When Shakeel Butt proposed a reclaim-oriented discussion, he was clear about his opinion on the current state of that code:

Memory reclaim in the kernel is a mess. We ship two completely separate eviction algorithms -- traditional LRU and MGLRU -- in the same file. mm/vmscan.c is over 8,000 lines. 40% of it is MGLRU-specific code that duplicates functionality already present in the traditional path. Every bug fix, every optimization, every feature has to be done twice or it only works for half the users. This is not sustainable. It has to stop.

He was joined by Emil Tsalapatis at the resulting session to try to find some answers to a problem that, he said, is getting worse. They would like to find some way to unify the kernel's two reclaim subsystems.

The methodology he proposed is not to pick a winner from the two alternatives but, instead, to find ways to unify the two as much as possible. That requires understanding both implementations well, which is complicated by the fact that the MGLRU developer has disappeared, and nobody really understands it at all, he said. (Subsequent discussion would make it clear that MGLRU is better understood than he thought). The unification task will need ways of evaluating performance — a good set of workloads that can reveal the strengths and weaknesses of specific algorithms.

Lorenzo Stoakes suggested modularizing the code as a useful first step; that might be a good way to increase the amount of code shared between the two implementations. Butt then went into his high-level plan, which had four steps:

Separate the two code bases into their own files, rather than having them both in one big file.
Define workloads that can be used to evaluate reclaim patches.
Find the common features between the two implementations.
Compare the implementations of each feature.

A participant questioned the plan to separate the files, worrying that it might confuse the Git history, but others generally seemed to think that some sort of cleanup was needed. Vlastimil Babka thought that separating the implementations might complicate the task of unifying them. Johannes Weiner said that MGLRU does not have much Git history in any case. We should separate what we can, he said, but there is a lot of intermingled code that will be difficult to tease out. Then ways should be found to implement features in common code used by both.

Chris Li mentioned that Kairui Song has a number of good MGLRU improvements pending (example); that work would not be helped by churning the code and creating a lot of conflicts. Improvements are good, he said, and we do not want to lose them. Butt agreed, but also said that this work should be evaluated based on whether it helps in the unification of the two implementations. Stoakes said that conflicts happen frequently in kernel development; they are managed and not allowed to block other work.

An audience member worried that some features are not easily measurable with a set of benchmarks. He mentioned, in particular, that MGLRU will resort much more quickly to the out-of-memory killer than the traditional LRU will; he saw that as a good feature that prevents thrashing.

Tsalapatis took over at this point to discuss the plan in more detail. It involves cleanly separating the two implementations to get a better sense of the structure of each and to see what is common between the two. The gathering of workloads will not try to create an exhaustive set; the purpose will be to get the important ones that can show improvements (or regressions). The definition of common features is an important part of this task; the two implementations have many features in common, but they use a different vocabulary to refer to them. Both implementations rely on a lot of heuristics; those need to be identified, with an eye toward any that are portable across both. For example, they calculate the ratio of file-backed to anonymous pages differently, and it is not clear why. Finally, for a unified implementation, decisions will have to be made between the available options for each feature.

He covered a number of examples, starting with page-table-entry harvesting, which is the process of getting information (primarily the "this page was accessed" bit) from the page tables. The traditional LRU walks entries using the reverse-mapping infrastructure, while MGLRU uses page-table scans. It would be interesting to try switching them around and, eventually, make this implementation generic.

The calculation of refault distance (essentially, how much time passes between when a page is reclaimed and it is faulted back in) is different between the two implementations, and he does not know why. The traditional LRU has an implementation that is "battle-tested"; perhaps MGLRU could switch to using it. The two implementations maintain different statistics counters; they will have to be unified if code is to be shared.

MGLRU, he said, gives priority to file-backed pages that have been mapped with mmap(); the traditional LRU, instead, avoids deactivating executable pages. These two heuristics might be equivalent, but Tsalapatis was not sure. The MGLRU marks pages that have been quickly refaulted; the traditional LRU, instead, moves them directly to the active list. When it comes time to reclaim within a control group, the traditional LRU will evict pages until the lower watermark is reached, while MGLRU has a more complex load-balancing algorithm.

The balance between file-backed and anonymous memory is one of the key heuristics applied by reclaim algorithms. The traditional LRU is driven by the swappiness setting, assisted by some special heuristics. MGLRU, instead, has its proportional-integral-derivative (PID) controller to drive that decision, but still takes swappiness into account. It is not clear that the PID controller is actually beneficial.

Song broke in at this point to say that answers to many of these questions can be found in his patch sets. He said he had chosen the wrong title, which should say "unify" somewhere.

Time was running out; Tsalapatis said that it sounded like there was an agreement on how to proceed. John Hubbard, though, was not so sure. He would like to see a single reclaim implementation in the kernel; developers should pick one that has the best of both of the current implementations, then move on. Splitting the two, he said, does not help in reaching that goal. Butt said that the ultimate goal was to have just one reclaim implementation in the kernel. Stoakes said that there might turn out to be good reasons to keep both, but developers won't know for a while; meanwhile, having them both in the same file is hurting. He thought there was a general agreement on cleaning things up.

Suren Baghdasaryan said that the plan generally looked good, and that the main contention was over splitting the two implementations. But he thought that the split should not be that hard, and that it could wait for the current work to be merged if need be. Weiner agreed, saying that the session had started with a claim that much of the system is not well understood and that the implementations should be unified. Song, he said, has already addressed a lot of that. Song's work should be the starting point, after which the split can happen. Li suggested that Song could do the split, but Weiner said that the task cannot be assigned in that way; this work needs to be a group effort.

The plan to improve MGLRU

The next day, Song ran a session of his own to describe the work he has done with the MGLRU and what he thinks should come next. The MGLRU, he said, is not perfect but it is "surprisingly good" for many workloads. It has lower locking contention than the traditional LRU, and its lazy-promotion scheme makes it relatively efficient. It has lower reverse-mapping overhead, and its built-in bloom filter helps it to focus on the hot areas of memory. An audience member asked how much that filter actually helps; Song answered that it is easy to measure, and the answer is that it helps quite a bit.

Song's goal is to make MGLRU "better and smarter". MGLRU performs better than the traditional LRU for many workloads now; the fact that it has been adopted by many distributions is a strong signal in that regard. It solves a number of practical problems; its time-to-live (TTL) heuristic helps to prevent thrashing, for example. Its working-set detection is getting better as well. One thing missing from MGLRU is writeback throttling for control groups; that is being fixed now, but global writeback throttling is still missing.

MGLRU makes a distinction between folios created in response to a page fault and others; the fault-instantiated folios are activated more quickly. This behavior comes from an assumption that applications expect memory reads to not stall, Song said, but reads from a file mapped with mmap() do not fit that model. There is a a patch from Barry Song that aims to fix this situation. He thought that it might be better to just remove this behavior, though.

There are metrics on the number of active and inactive pages maintained in /proc/meminfo, but MGLRU doesn't manage them well, with the result that the numbers are "jumpy". It deems the two youngest generations of pages as being active, leading to big changes when the generations age. There is work underway (in the "MGLRU-FG" patch set) to fix that problem.

Another problem is that MGLRU does not adequately protect the page cache, Song said. Workloads with a lot of anonymous pages perform well, but those that are more dependent on the page cache can regress. It's not just a matter of balancing, he said, but properly identifying the working set; the PID controller is not doing that properly. The MGLRU-FG work aims to unify the metrics in this area and improve working-set detection; the result is significantly better performance.

David Hildenbrand said that, when MGLRU was merged, the plan was to make it the default; he asked Song why people would choose not to use it now. Song answered that many distributions have switched, but there are users who are running into regressions in page-cache performance. Once that problem is fixed, he said, he sees no reason not to just use MGLRU.

Hildenbrand then asked about page-flag usage; those bits are in short supply, and MGLRU uses a number of them. The MGLRU-FG series reduces that usage from four to three bits, Song said. Hildenbrand asked if that meant MGLRU could now be used on 32-bit systems (which have fewer page flags available); a unified reclaim implementation must work on "all the architectures we don't care about". Song said that the flag usage could be reduced to two, but with a slight performance impact.

The pace increased toward the end of the session as Song mentioned some of the other things he has been working on. He is trying to unify the calculation of refault distance between the two implementations. A "traditional-LRU compatibility mode" can be implemented by reducing the number of generations and tiers to two. He is also working to increase the number of generations (normally set to four) while reducing the associated use of page flags; eventually it should be possible to support 64 generations. Matthew Wilcox asked how much better 64 would be; Song didn't really have an answer but said that the cost of running the experiment is low.

An idea for the future would be to extend MGLRU using BPF; it would provide a hook to allow a BPF program to decide which generation a faulted folio should be placed into. Another hook could allow a program to move a folio to a different generation on access. That would allow the implementation of a number of different reclaim policies, under administrator control. As time ran out, one audience member suggested that this might be overkill.

MGLRU on Android

Zicheng Wang works for HONOR, a smartphone manufacture that has chosen to enable MGLRU on all the devices it ships — that is about 70 million devices running MGLRU overall. Android, he said, heavily overcommits memory and needs aggressive reclaim to perform well. But that reclaim operation must fit into an 8.3ms time budget; anything longer might cause rendering stalls on a 120-frame-per-second screen. Reclaim cannot be allowed to block critical paths.

The Android app lifecycle starts with launch, he said, followed by transitions between the foreground, background, and frozen states. Android tends to preload a lot of pages in the early stages for quick launch, relying on aggressive reclaim to clean up the memory that is not needed. MGLRU, he said, reclaims too many file-backed pages, degrading performance in some scenarios; that can lead to a slower camera launch, for example. One solution to this problem is active aging; when an app goes into the background, its pages are targeted for aging. That helps to distribute anonymous pages across the generations, and yields significant improvements at the cost of a bit more CPU usage.

MGLRU makes it hard to control how much reclaiming is done; it continues to reclaim pages after the target watermarks have been hit. Among other things, that breaks the time budget that reclaim must fit into. HONOR has addressed this problem by adding a hook to tell MGLRU when it is time to quit.

Throttling of processes in direct reclaim can put tasks to sleep waiting for the kswapd kernel thread to free more memory; that is causing threads to stall for too long. The problem seems to be that kswapd is wasting a lot of time scanning control groups that will yield little reclaimable memory. He had no real solution for that problem.

A foreground app's file-backed pages can be frequently reclaimed, causing increased latency as they must be faulted back in. He has addressed that by adding a hook to skip over the foreground app during reclaim. There is also a problem with the automatic activation of pages brought in by the readahead code; that can activate pages that will never be used, at the expense of the pages an app actually needs.

To conclude, Wang said that he would like to see some sort of generic interfaces provided by MGLRU; that would be better than the current vendor-specific hacks. The parameters that control aging should be exposed, he said. There are some knobs currently in debugfs that, perhaps, should move to sysfs so they could be made available on production systems. And, he said, MGLRU needs better awareness of the priorities of the tasks running on the system.

The session concluded without discussion.

Wang has posted the slides from this session.

In search of faster this_cpu operations

By Jonathan Corbet
May 19, 2026

The kernel's this_cpu operations are meant to speed access to per-CPU variables. They are more optimal on some CPUs than others, though. During a memory-management-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Yang Shi proposed a fundamental, and somewhat controversial, change to how these operations work in order to provide better performance on a wider range of architectures.

Per-CPU variables are organized as an array, indexed by CPU number, with each CPU's data being placed in a separate cache line; that allows CPUs to access their private data without locking overhead or contention from other CPUs. On the x86 architecture, a per-CPU access is implemented by prefixing the relevant instruction with a segment register, creating a single-instruction operation that executes atomically. Other architectures, including Arm, lack segment registers and, as a result, have a more complicated implementation. In particular, the calculation of the address and the access of the data behind that address must be done separately, turning a per-CPU access into a multi-instruction sequence.

That is a significant difference. If a multi-instruction sequence is preempted partway through, the newly running thread could access the same variable, leading to all sorts of unpleasant behavior. Migration of the thread could lead to cross-CPU access, which is also undesirable. To prevent these scenarios, the this_cpu operations must disable preemption on the affected architectures, which hurts performance.

Shi's proposal is to reimplement per-CPU variables so that any given variable has the same address on every CPU, using per-CPU page tables to make that work. That would eliminate the index calculation and preemption would no longer be a problem. The only problem with this scheme is that it would break the per_cpu_ptr() macro that is used to initialize data across all CPUs. To solve that problem, per-CPU variables would be mapped twice. The existing global mapping would be retained and used for initialization; a second mapping would be specific to each CPU.

Jason Gunthorpe pointed out that, in the past, Linus Torvalds has been strongly opposed to using per-CPU page tables in this way. If his concerns are not addressed, Gunthorpe said, this work will not go far. The objection seems to be based on the difficulty of correctly managing translation lookaside buffer (TLB) entries associated with those addresses; there was some discussion about whether that situation has improved with more recent architecture revisions. It was also pointed out that, while this scheme would eliminate the need to disable preemption in some situations, any sort of update involving more than one instruction would still need to be executed with preemption disabled.

Shi continued, saying that the new implementation does have a cost in the form of higher address-space usage; that cost appears to be small, though. The per-CPU page tables will need to occupy physical memory; he said that cost is about 2MB on a 160-core machine. Some extra page-table operations are needed for the allocation and freeing of per-CPU variables. There may also be a need to allocate a dedicated range of virtual address space, which could be a problem on 32-bit machines.

Performance benchmarks were run on a 160-core Arm system; the key kernel-build benchmark showed a 13-18% reduction in system time, and ran in 3-7% less wall-clock time. The stress-ng benchmarks showed significant improvements as well. Brendan Jackman expressed surprise at how large those numbers were; avoiding the need to disable preemption does not seem like enough to explain the difference. Some more investigation into the cause of the speedups is indicated, he said.

As time ran out, Ryan Roberts wondered if the in-kernel restartable-sequences work from Peter Zijlstra might be an alternative solution to this problem; Shi was not familiar enough with that work to say. Shi did say that the per-CPU page tables could, in the future, also be used for replication of the kernel text across NUMA nodes, providing local access across the system. Jackman said that they could make his proposed "mermap" (which was discussed earlier in the conference) work better as well.

Comments (3 posted)

The tenth OpenPGP email summit

May 20, 2026

This article was contributed by Heiko Schäfer, Andrew Gallagher, and David Runge.

The OpenPGP Email Summit is an annual meeting for those who work on encrypted email and related topics. The tenth installment of this meeting took place in March 2026 and the minutes have now been published. As usual, a wide range of topics were discussed. Highlights included support for post-quantum cryptography (PQC) with multiple actors planning rollouts within this year, a promising new approach for making email signatures ubiquitous with the plan of making OpenPGP signed email a default, a new draft that brings reliable deletion (or "forward secrecy") features to OpenPGP, as well as a plan for transferring ownership of the OpenPGP.org domain.

The summit attendees represented many projects, providers, and other interested parties in the space including Delta Chat, FreePG, Hagrid, Hockeypuck, keys.openpgp.org (KOO), Proton, Ripasso, RNP, Sequoia-PGP, Signstar, Thunderbird, VOA, and others.

Governance and the openpgp.org Domain

Phil Zimmermann is the current owner of the OpenPGP.org domain. He was not at the summit, but he had communicated that he wants to hand off this digital asset to the community; the community would prefer to find a setup that doesn't require any individual to take on personal responsibility. The keys.openpgp.org (KOO) board is one existing governance body that could take over the domain. Its current mandate is narrowly focused on running the keys.openpgp.org keyserver.

It is exploring taking on responsibility for the domain, using the Wau Holland Foundation as a trustee. The foundation is loosely connected with the Chaos Computer Club (CCC) and has been the sponsor of the OpenPGP email summit over the past ten years. Its members are deeply invested in the proliferation of the OpenPGP ecosystem. As a next step, the KOO board has proposed a constitutional change to the voting body.

PQC in OpenPGP

PQC was one of the topics discussed at this summit. Throughout the industry, people are preparing for the eventuality that quantum computers might at some point be able to break the current crop of cryptographic algorithms. In such a scenario, an attacker could even collect today's encrypted messages to decrypt them later, once a sufficiently capable quantum computer is available. PQC algorithms are designed to be unbreakable even by potentially upcoming quantum computers. The IETF draft that specifies PQC support for OpenPGP has completed last call and is awaiting final approval by its authors. Formal ratification as an RFC is expected within the next few months. The format itself has been stable for about a year.

The draft specifies two composite algorithms for encryption, two composite algorithms for digital signatures and three PQC-only algorithms for digital signing. All seven algorithms are usable with the new OpenPGP key format, (specified in RFC 9580), commonly referred to as "v6". In addition, one of the composite encryption algorithms is designated for use with the currently common v4 keys (see below for more).

Proton, a company that provides OpenPGP encrypted mail services, already had a complete implementation of PQC support for its email service at the time of the summit. General availability has since been announced. The core parts of Proton's PQC implementation are available as free software in feature branches of the two OpenPGP libraries that Proton uses and maintains: GopenPGP and OpenPGP.js.

The Delta Chat secure-messaging project has all the building blocks for PQC support in place, and intends to roll it out in production later this year. Thunderbird has experimental support for sending and receiving v4 PQC-encrypted messages. Providing this feature in stable releases will still take some time, though. Thunderbird uses the RNP OpenPGP library; the library's maintainers are working on incorporating a sizeable PQC pull request that was developed as part of a project financed by Germany's Federal Office for Information Security (BSI). The Hockeypuck keyserver has also added support for composite PQC keys in its latest beta release.

PQC encryption for v4 keys

The v6 format supersedes the previous format (referred to as "v4", and specified in RFC 4880) The changes in the v6 key format itself are moderate. The main point of the new key version is that fingerprints for v6 keys use SHA2-256 hashes, while v4 keys use SHA1 hashes as fingerprints. Attacks on the SHA1 hash algorithm have become sufficiently serious that moving on from v4 keys seems to be the prudent long-term strategy.

However, transitioning the ecosystem to a new key version is a longer-term project. As the urgency of protecting communication against possible post-quantum attacks increases, allowing users to seamlessly upgrade their existing v4 keys to enable PQC encryption becomes more of a concern. To serve this need, the PQC draft explicitly designates ML-KEM-768+X25519 composites for use as v4 subkeys. Users can add a post-quantum encryption subkey with this algorithm to an existing v4 key, without requiring their correspondents to support the still nascent v6 key format.

Thunderbird plans to roll out PQC support for v4 keys with additional ML-KEM-768+X25519 encryption subkeys by the end of this year, presupposing an RNP release with support for the format. The availability of PQC in both v4 and v6 formats allows for a more flexible rollout of PQC support, depending on the needs and priorities of different projects. The two current OpenPGP modernization efforts—v6 key support and PQC support—can be tackled separately or in combination.

Since many libraries support the full range of formats, there should usually be a common denominator, even if projects upgrade their support on different timelines.

FreePG and PQC

FreePG is a patched version of GnuPG that is used partially or fully by many of the larger Linux distributions. Its main goal is adherence to the OpenPGP IETF standard to allow users of GnuPG to opt out of the upstream's increasing divergence from the OpenPGP standard. However, FreePG is designed as a temporary stopgap rather than a long-term fork.

Its maintainers clarified that adding support for the IETF PQC draft is non-trivial, and the available resources may be too limited to achieve support for it in FreePG in the short term. The group agreed that FreePG should at least be able to gracefully ignore v4 PQC encryption subkeys, even if it cannot use them. As long as GnuPG upstream doesn't support v6 keys, it's not feasible for FreePG to support any v6 formats, including v6 PQC keys.

Separate from FreePG, Hamming Quasi-Cyclic (HQC), a new post-quantum encryption algorithm, was discussed briefly. There is interest, but also consensus that it's too soon to start specifying use of the algorithm in OpenPGP.

Unobtrusive signatures

Unobtrusive signatures, as described in a new IETF draft, were also discussed this year. The idea was initially brainstormed during the previous (9th) email summit. Existing email signature schemes (which use a multipart/signed structure) are not handled gracefully by all email software. As a result, many users turn signature generation off, to avoid displaying harmless but confusing errors to the recipient.

The goal of unobtrusive signatures is to allow sending software to confidently enable signing by default, without risking complaints to its users from recipients with clients that do not support signatures. Unobtrusive signatures unblock this default because they are silently ignored by software that doesn't support them. Previously, OpenPGP signatures would confuse or even worry some email recipients, causing them to complain to senders. Thus, developers of email software were sometimes reluctant to enable signatures by default, since it could cause complaints from recipients who do not have support for signatures.

The new approach uses a multipart/mixed wrapper with an OpenPGP signature embedded as a header rather than an attachment. This construction allows unobtrusive signatures to fulfill their main goal, which is to never be displayed in a way that confuses recipients. Even legacy clients that do not understand the signature will render the rest of the email as normal, without displaying anything about the signature. On the other hand, clients that support unobtrusive signatures can verify the signature and signal success to the user.

At the time of the summit, an implementation of the scheme was available in development versions of Thunderbird, and has already seen some successful testing by users in the wild. Thunderbird Daily, a rolling release of the mail client that tracks development and includes bleeding-edge features, can already produce and consume unobtrusive signatures, though it currently requires users to enable a hidden preference. Kai Engert from Thunderbird estimates that production of unobtrusive signatures will start becoming the default later this year. Proton plans to implement support for incoming unobtrusive signatures soon as well.

Bart Butler from Proton observed that once both Thunderbird and Proton support unobtrusive signatures, it should be straightforward to bring other clients on board, making this effort one of the highest return-on-investment improvements for signed email.

Autocrypt v2 (AC2): Combining PQC and reliable deletion

Holger Krekel from Delta Chat presented Autocrypt v2 (AC2), a specification that was in part driven by Delta Chat project members (minutes of the discussion). AC2 deals with a separate concern than Autocrypt v1. While v1 handles exchange and update of OpenPGP keys between email peers, AC2 centrally introduces a scheme for clock-based rotation of key material. It doesn't concern itself with bindings between identities and key material.

The AC2 draft's introduction outlines the goals:

It offers defense against store-now-decrypt-later attacks from quantum computers through post-quantum hybrid cryptography. It also enables reliable deletion ("Forward Secrecy") of received messages even when adversaries capture encrypted messages in transit and later compromise the user's message archive and secret keys.

That is, if all participants in a chat don't retain decrypted message plaintext, and regularly destroy old private key material (as the scheme prescribes), then old plaintext becomes fundamentally unrecoverable over time by correspondents or attackers. Autocrypt v2 combines this clock-based key-rotation scheme with PQC encryption.

The key-rotation scheme combines a permanent fallback key with a short-lived encryption subkey (for example, valid for ten days). Communication usually relies only on the short-lived key, but can fall back to the long-lived encryption key in edge cases (for example when two peers have not communicated for a longer time). Senders regularly distribute new subkeys. Recipients merge their peers' encryption subkeys locally, while removing obsolete subkeys as they expire.

There was some discussion about the inherent tradeoffs of this scheme. Reliable deletion means that old messages are not readable anymore by anyone. This property is in tension with typical expectations of email, where messages are often stored indefinitely (e.g. on IMAP servers), and users expect to be able to decrypt and read them in the future. By contrast, if a client deletes its decryption subkey, but the ciphertext persists on a server, the user loses access to their old mail. Possible mitigations—re-encrypting messages to a long-term key, storing session keys separately—trade away some of the forward secrecy guarantee.

There was no conclusion, but it's clear that different use cases exist, and forward secrecy is not a good fit for all of them. The AC2 framework can be applied to realize different outcomes by choosing between the different tradeoffs.

Another question that was raised, but not resolved, was whether Autocrypt v2 certificates should be explicitly marked as such. This might be helpful as a hint, for example, to prompt keyservers to prune expired encryption subkeys rather than accumulating them indefinitely.

HKPv2: Modernized general key-server API

The OpenPGP ecosystem currently has three somewhat ad-hoc technologies for certificate distribution. The Hockeypuck servers implement the "Legacy HTTP Keyserver Protocol" (HKPv1). The Hagrid server at keys.openpgp.org uses the custom Verifying Key Server (VKS) API, but also implements a subset of HKPv1. A third scheme, named Web Key Directory (WKD) allows static serving of OpenPGP key material for lookup by email address.

HKPv2, which was discussed at this summit, is a proposal that aims to cover all use cases of these three key-distribution systems with one unified API. It is designed to cover both verifying and non-verifying key-server use cases, and also for serving certificates directly from a set of plain static files (akin to WKD, without requiring any specialized software on the server). This draft has arrived at a relatively stable state and is specifically designed to facilitate the ecosystem's shift from classic v4 keys to v6 and/or PQC keys.

The 2025 keys.openpgp.org board has discussed and worked on the HKPv2 draft, and arrived at the decision that keys.openpgp.org will implement support for the protocol (as soon as the limited development resources allow).

The Hockeypuck key-server software has since added preliminary support for the API. The 2025 keys.openpgp.org board also decided for the project to implement the API, but there is no clear timeline for this effort yet. The HKPv2 draft is currently waiting for adoption by the IETF OpenPGP working group.

Key migration and the key replacement draft

Upgrading from OpenPGP v4 keys to v6 keys, and/or PQC keys, was discussed briefly. In the near future, many OpenPGP users are going to consider upgrading from their current v4 keys to new v6 and/or PQC keys. Such key migrations have historically been a mostly manual process in OpenPGP: key holders created new keys, and issued various certifications between their certificates to mark them as linked. Their correspondents needed to manually determine if the new certificates were reliably linked to trusted previous certificates, and accept the new certificates in their OpenPGP software.

The key replacement draft defines a mechanism that formalizes key transitions, and enables software to handle them transparently, on behalf of users (both for key holders and for their correspondents).

Given good support in applications, this mechanism will make key transitions close to seamless—while at the same time being rigorously protected by cryptographic statements from the key holder. This draft was adopted by the OpenPGP working group, and has been textually mostly stable for a number of months, but is still waiting for implementations before entering "last call".

Looking Ahead

A number of concrete next steps were announced at this summit. Thunderbird and Proton announced plans to ship unobtrusive signatures in upcoming releases of their respective software. Thunderbird is also planning to add complete v4 PQC support in an upcoming stable release. Proton confirmed its intention to roll out v6 PQC support to all of its users, after successful internal testing. Delta Chat is planning to roll out v6 PQC and "reliable deletion" via Autocrypt v2 to its users in 2026. The support for HKPv2 in the Hockeypuck keyserver software will be finalized and rolled out to the relevant keyservers this year, alongside support for PQC keys. It was also confirmed that keys.openpgp.org intends to add HKPv2 support to the Hagrid keyserver, but no clear roadmap for implementation has been put forth yet.

A number of longer-term efforts remain under active development. Many participants said that this year's summit was extremely productive. The OpenPGP ecosystem is looking diverse and vibrant; many long-term projects are currently coming to fruition. In particular, the finalization of PQC support in OpenPGP (which was kicked off in 2021 by Germany's BSI), and the multitude of imminent related rollouts, appear to be timely.

A followup interim meeting is scheduled for October 21, 2026; the next in-person summit tentatively for the end of April 2027. Anyone interested in participating can subscribe to the IETF Open Specification for Pretty Good Privacy group's mailing list. Participation is open to anyone.

Comments (11 posted)

Page editor: Joe Brockmeier

Brief items

Kernel development

Kernel release status

The current development kernel is 7.1-rc4, released on May 17. Linus said:

Some of the documentation updates might be worth highlighting: the continued flood of AI reports has basically made the security list almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools. People spend all their time just forwarding things to the right people or saying "that was already fixed a week/month ago" and pointing to the public discussion.
Which is all entirely pointless churn, and we're making it clear that AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved - and only makes that duplication worse because the reporters can't even see each other's reports.

(He is referring to this pull request with patches from Willy Tarreau defining what constitutes a security bug and responsible ways to use AI to find bugs).

This development cycle has brought in 13,963 non-merge changesets from 2,217 developers, 417 of whom are first-time kernel contributors. The release history looks like:

RC Date Commits

v7.1-rc1 2026-04-26 13963 13963

v7.1-rc2 2026-05-03 475 475

v7.1-rc3 2026-05-10 584 584

v7.1-rc4 2026-05-17 428 428

RC	Date	Commits
v7.1-rc1	2026-04-26	13963	13963
v7.1-rc2	2026-05-03	475	475
v7.1-rc3	2026-05-10	584	584
v7.1-rc4	2026-05-17	428	428

See the LWN KSDB 7.1 page for lots more details.

Stable updates have, once again, not been in short supply. 7.0.7, 6.18.30, and 6.12.88 were released on May 14, 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207, and 5.10.256 on May 15, and 7.0.9, 6.18.32, 6.12.90, and 6.6.140 on May 17.

Quote of the week

It should also be noted that Intel's zero-day bot was (a) closed source, and (b) was sending its test regression reports with the linux-kernel mailing list cc'ed, and no one really complained because it was so useful, and if Intel was willing to use very expensive hardware in their data center to contribute reports, so long as the reports were useful and the false-positive noise was low enough, we decided to be grateful and not worry (too much) about the fact that Intel's zero-day bot was closed source. (There was indeed some grumbling in the bar at Plumbers, of course. :-)
In my opinion, we should be doing the same for Sashiko, and that's the decision which the ext4 developers have made --- at least for ext4 patches.

— Ted Ts'o

Comments (3 posted)

Distributions

Distributions quote of the week

Until further notice, it's probably just a good idea to assume there will be an urgent #fedora kernel security update every day.

— Adam Williamson

Development

Firefox 151.0 released

Version 151.0 of the Firefox browser has been released. Significant changes include the ability to clear and restart a private-browsing session, better fingerprinting protection, control over the apparent location when using the Firefox VPN, and more.

Comments (3 posted)

pgBackRest will continue

In April, David Steele, maintainer of the popular pgBackRest backup and restore project for PostgreSQL, announced that he had archived the project and it would no longer be maintained due to lack of sponsorship. On May 18, he announced that a number of sponsors have stepped forward to ensure its continued development:

Over the last few weeks, a coalition of sponsors has come together to fund ongoing development. Their support means the project is no longer reliant on a single sponsor, giving pgBackRest the stability it needs for the long term.

[...] I'm looking forward to getting back to work. There are features and optimizations in the pipeline that I'm excited to share in upcoming releases. Thank you to our sponsors for making this possible, and thank you to the community for your patience and support during this transition.

Thanks to Paul Wise for the tip.