The 2019 Linux Storage, Filesystem, and Memory-Management Summit

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

The Linux Storage, Filesystem, and Memory-Management Summit is an annual, invitation-only gathering of core-kernel developers; it is one of the most intensive and technical events on the annual calendar. The 2019 LSFMM Summit was held April 30 to May 2 in San Juan, Puerto Rico; it was supplemented this year by a special track dedicated to the BPF virtual machine. Once again, LWN was there and able to cover a portion of the sessions.

Our coverage is a work in progress; the articles that are available at this point are:

Plenary sessions

There were a few sessions of general interest attended by all developers at the event.

• System observability with BPF: Brendan Gregg discusses the "superpowers" made possible by the combination of tracing infrastructure and BPF.
• Containers and address space separation: James Bottomley describes the need for a way to separate containers (and virtual machines) from each to help support multi-tenant systems.
• Cleaning up after dying control groups: deleted control groups can continue to haunt the system for a long time.
• Testing and the stable tree: as more patches are added to the stable tree, there is a need for more and better testing of it.
• get_user_pages(), pinned pages, and DAX: a heated session on the longstanding problems with get_user_pages().
• Alignment guarantees for kmalloc(): should there be stronger assurances about the alignment of allocated memory objects?
• BPF: what's good, what's coming, and what's needed: Dave Miller talks about what BPF can do now, and what to expect in the future.
• A kernel debugger in Python: drgn: a presentation of a kernel debugger that allows interactive examination of data structures in the running kernel.

Filesystem sessions

The filesystem developers discussed the following topics in their track:

• Improving fget() performance: fget() and fput() are using more CPU time than expected for certain workloads; is there anything that can be done to fix that?
• Taking ZUFS upstream: a discussion about how the "zero-copy user-mode filesystem" (ZUFS) could get merged into the mainline.
• DAX semantics: a discussion on what the semantics of a per-inode flag to indicate files that should be accessed via DAX should be.
• NFS topics: a discussion of ongoing work on NFS in the kernel.
• A filesystem for virtualization: a discussion about the virtio-fs filesystem for KVM guests to share filesystems from the host, and some features that still need to be worked out.
• Common needs for Samba and NFS: a discussion about some needs for network filesystems that might best be addressed by kernel changes.
• Filesystems and crash resistance: is there a way to provide an alternative to fsync() that provides the guarantees that application developers want?
• Asynchronous fsync(): a discussion about the longstanding idea of a bulk fsync() that could be used by large-scale data migration applications.
• Lazy file reflink: a discussion on ways to provide better file notifications for specialized use cases.
• The Linux "copy problem": a discussion on performance problems with copy operations and on ways to potentially address them.

Filesystem and storage sessions

Some sessions were shared discussions involving both storage and filesystem developers:

• Issues around discard: Dennis Zhou brings up some problems using discard—telling the block device that some blocks are no longer being used—and looks for ways to handle them better.
• Supporting the UFS turbo-write mode: a new mode for Universal Flash Storage (UFS) devices is meant to speed up write operations, but there are questions on what the kernel should do to support it.
• Filesystems for zoned block devices: a discussion on support for zoned block devices in Btrfs and a new filesystem, ZoneFS, to provide another means of accessing shingled magnetic recording (SMR) and other zoned devices.
• Storage testing: making it easier for more kernel developers to run testing for the block layer.
• A way to do atomic writes: a discussion about adding a feature for atomic writes at the filesystem layer.

Filesystem and memory-management sessions

There were a few sessions for both the filesystem and memory-management developers:

• Transparent huge pages for filesystems: a possible first step toward supporting transparent huge pages for file pages.
• Shrinking filesystem caches for dying control groups: a follow-up discussion that focused on the filesystem caches for control groups that are dying.

Memory-management sessions

The memory-management developers sequestered themselves to dive into a number of detailed topics:

• Toward a reverse splice(): do we need a new version of the splice() system call, and what form would it take?
• Memory encryption issues: what sort of security does memory encryption provide, and how can it be supported in the kernel?
• Android memory management: the unique challenge of memory management in the Android world, with a focus on opportunistic reclaim.
• The end of the DAX experiment: is the kernel's DAX feature finally done?
• Write-protect for userfaultfd(): extending user-space page-fault handling to intercept write operations.
• The search for available page flags: how can we get more of this resource that is perennially in short supply?
• Minimizing the use of tail pages: a proposed optimization to how the kernel works with compound pages.
• NUMA nodes for persistent-memory management: a pair of sessions on extending the NUMA abstraction to handle persistent memory.
• Transparent huge pages, NUMA locality, and performance regressions: dueling regressions have highlighted a problem with how huge pages are allocated on NUMA systems.
• Proactively reclaiming idle memory: a scheme to avoid direct reclaim by grabbing memory that appears not to be in active use.
• Remote memory control-group charging; memory usage is sometimes charged to the wrong control group, and that is not always a bad thing.
• How to get rid of mmap_sem: three separate sessions, all devoted to finding ways to address the lonstanding mmap_sem scalability problems.
• The memory-management subsystem development process: a discussion with Andrew Morton on how the development process can be improved.
• Improving access to physically contiguous memory: another look at the ancient problem of large, physically contiguous allocations.
• Memory management for 400Gb/s interfaces: Christoph Lameter describes the challenges we face in keeping up with present and future data transmission speeds.
• Presenting heterogeneous memory to user space: two proposals for ways to make exotic device-based memory available to applications.

Group photo

Acknowledgments

Thanks to the LSFMM 2019 program committee for inviting LWN to the event, and to the Linux Foundation, LWN's travel sponsor, for supporting our travel to Puerto Rico.

---

(Log in to post comments)