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

Every year, the Linux Storage, Filesystem, and Memory-Management Summit (LSFMM) brings together 80 or 90 core kernel developers for a few days of highly technical discussions. The 2018 LSFMM was held April 23 to 25 in Park City, Utah. As usual, LWN was there and able to attend most of the sessions.

Plenary sessions

This year, a relatively small subset of the discussions involved the entire group of developers. Topics addressed by the whole group include:

• Filesystem metadata memory management: looking for ways to improve the management of memory used to hold filesystem metadata caches.
• Repurposing page->mapping: two separate sessions about freeing up the mapping field in the page structure for more productive uses.
• The impact of page-table isolation on I/O performance: how much does PTI slow I/O down?
• A mapping layer for filesystems: a way to handle space-management issues for filesystems on thin-provisioned devices that gives rise to a number of other uses.
• The trouble with get_user_pages(): the kernel's mechanism for providing access to user-space pages can fail badly in some situations.
• Willy's memory-management to-do list: a grab-bag of memory-management issues from Matthew Wilcox, plus a bonus session on reworking struct page.

Memory-management track sessions

The discussions held by the memory-management subgroup were:

• A page-table isolation update: the current status of the kernel page-table isolation patches and how developers can avoid the worst performance impacts.
• Supporting memory encryption: newer Intel and AMD processors can do memory encryption, but supporting that feature in the kernel presents some challenges.
• Heterogeneous memory management and MMU notifiers: a pair of sessions on HMM and the notifier mechanism it depends on.
• Exposing storage devices as memory: a proposal for a new character-device abstraction for fast access to storage devices.
• Rethinking NUMA: is the NUMA abstraction sufficent to describe today's memory architectures?
• The memory-management development process: a discussion on the health of the development community and what might be done to make things work better.
• The LRU lock and mmap_sem: two sessions on difficult locking problems in the memory-management subsystem.
• The slab and protected-memory allocators: two sessions on allocators for relatively small objects.
• Three sessions on memory control groups: various issues, including background reclaim, swap accounting, and out-of-memory handling.
• Improving support for large, contiguous allocations: sessions on the contiguous memory allocator and gigantic page allocations.
• Toward better performance on large-memory systems: addressing some scalability issues on the largest systems.
• Zone-lock and mmap_sem scalability: two more sessions on lock-contention issues in the memory-management subsystem.
• Hotplugging and poisoning: problems with adding memory to and removing memory from running systems, whether it be a deliberate action or as a response to hardware trouble.
• get_user_pages() continued: looking at possible solutions to the problem.
• Reworking page-table traversal: a proposal for a new way of making changes to ranges of page-table entries.
• Is it time to remove ZONE_DMA?: a holdover from the past may be reaching the end of its run.

Filesystem track

The filesystem developers participated in the following sessions:

• Removing the kthread freezer?: more discussion on how to make progress in the longtime effort to get rid of the kthread freezer.
• Fixing error reporting—again: looking at ways to better report errors to user space and to hopefully fix problems that recently bit PostgreSQL.
• File-level integrity: a feature akin to dm-verity that allows detection of on-disk alteration of individual files.
• A kernel integrity subsystem update: an overview of the subsystem that measures and appraises file contents.
• Controlling block-I/O latency: providing a means to specify a latency target for the block-I/O controller.
• A new API for mounting filesystems: mount() has some downsides; a proposed new API would try to provide something better.
• XFS parent pointers: a new XFS feature that will make it possible to reconstruct paths from inodes.
• Shared memory mappings for devices: supporting GPUs and other devices that need to share device memory among multiple processes.
• XFS online filesystem scrubbing and repair: a discussion of filesystem scrubbing and whether common interfaces and tools could be developed.
• The NOVA filesystem: a look at a proposed Linux filesystem that exclusively targets non-volatile memory.
• PostgreSQL visits LSFMM: a discussion led by PostgreSQL developer Andres Freund on the problems the database system has recently encountered.
• Network filesystem topics: a look at some needed features to better support SMB, NFS, and others.
• SMB/CIFS compounding support: some discussion of support for compounding—combining multiple network filesystem operations into a single server message.
• Case-insensitive filesystem lookups: a proposal for a way to add case-insensitive filesystems to the kernel.
• A filesystem "change journal" and other topics: a way to get reliable notifications of filesystem changes, even after a crash, was discussed along with performance-regression testing for filesystems.
• The ZUFS zero-copy filesystem: an introduction to a user-space filesystem framework targeted at zero-copy operation for persistent memory.
• Flash storage topics: a variety of problem areas for flash storage and filesystems on Android.
• Messiness in removing directories: Al Viro reported on some problems he found in the rmdir() implementation.
• Filesystem test suites: a discussion of how to make filesystem test suites more accessible to other developers.
• XArray and the mainline: the status of the XArray radix-tree replacement API.

Filesystem and Storage track sessions

There were a few sessions shared by participants in both the Filesystem and Storage tracks:

• Supporting multi-actuator drives: a discussion about the design of the interface to devices with multiple actuators that provide multiple sets of read/write heads for parallel data access.
• An update on bcachefs: a discussion on bcachefs and whether it is ready for mainline inclusion.
• Handling I/O errors in the kernel: what to do about I/O errors, particularly during writeback?

Group photo

Acknowledgments

Thanks to the LSFMM 2018 program committee for inviting LWN to the event, and to the Linux Foundation, LWN's travel sponsor, for supporting our travel to Park City.

Index entries for this article
Conference	Storage, Filesystem, and Memory-Management Summit/2018

---

to post comments