The 2015 Linux Storage, Filesystem, and Memory Management Summit

Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

The Linux Storage, Filesystem, and Memory Management Summit is arguably the most severely technical event on many kernel developers' schedules. The 2015 event, held March 9 and 10 in Boston, was no exception. Discussions over these two days went deeply into a wide range of topics of interest to the core kernel development community.

As usual, LWN was present at the event. Writeups of the individual sessions are in progress; they will appear here once they are ready.

Plenary sessions

Some topics were deemed to be of interest to the entire assembled group of developers. The plenary sessions held at the summit were:

• Persistent memory: where we stand with regard to support for large persistent-memory devices and where the remaining challenges are.

• Allowing small allocations to fail. The news that the memory-management subsystem generally does not allow small allocation requests to fail under any circumstances came as a surprise to many developers. There seems to be a consensus that this behavior should change, but effecting that change will be a multi-year prospect.

• Reservations for must-succeed allocations: the continuation of the discussion on improving the handling of low-memory situations.

• Virtual filesystem changes: Al Viro talks about what is happening in the VFS layer and what developers can look forward to in the near future.

• Investigating a performance bottleneck: a brief, low-energy session trying to debug an obscure problem at the end of the first day.

Memory-management track sessions

• Improving huge page handling; two sessions devoted to problems associated with huge pages and how they might be addressed.

• User-space page fault handling: the current state and future direction of the userfaultfd() patches.

• Fixing the contiguous memory allocator: the CMA code has turned up a number of problems that will not be entirely trivial to address.

• Heterogeneous memory management: sharing memory between the CPU and GPUs or other devices.

• Issues with memory control groups: there are far fewer problems here than in the past, but there are still ways of making memory control groups work better.

• Memory-management scalability: how to work faster and better on ever-larger systems, with a special focus on the mmap_sem semaphore.

• Testing and debugging, with various sessions looking at mmtests, MPX, VM_BUG_ON(), KASan, and more.

• Improving page reclaim with an emphasis on performance on large persistent-memory devices.

• Huge pages and persistent memory. Large-memory devices naturally call for the use of large pages to reduce overhead, but there a number of details to work out on the way there.

Filesystem/storage track sessions

A number of sessions were shared between the filesystem and storage tracks, especially on the first day of the Summit.

• Filesystem/block interfaces: how can communications between these two layers be widened and made more flexible?

• Overlayfs issues and experiences: the overlayfs union filesystem has been in the mainline since 3.18; that has been enough time for a number of issues to arise and, in some cases, be solved.

• Asynchronous buffered read operations: the preadv2() system call and related topics.

• Handling 32KB-block drives: disk drive manufacturers are pushing toward larger native block sizes; what will it take for the kernel to be able to work with such drives?

• Filesystem support for SMR drives; shingled magnetic recording devices have a number of constraints that make them hard to drive from Linux. Is it possible to run Linux filesystems over SMR drives, and, if so, is it worth the effort?

• Power-failure testing: making filesystems more robust even when power goes out at the worst possible time.

• Copy offload: getting a filesystem or storage system to do the work of copying files so user space doesn't have to.

Filesystem track sessions

The sessions involving just the filesystem developers were:

• NFS performance: what to do about a number of network filesystem performance bottlenecks.

• Filesystem defragmentation. All filesystems tend to fragment over time; what can be done to clean them up again?

• Identity and filesystems: a brief session on how to better manage user and group ID mapping for filesystems.

• Issues with epoll(): addressing some of the scalability issues that have come up with the epoll() system calls.

---

(Log in to post comments)