Please consider subscribing to LWNThe 2017 Linux Storage, Filesystem, and Memory-Management Summit was held March 20 and 21 in Cambridge, MA. Around 100 kernel developers gathered to discuss many topics of interests in what has traditionally been one of the most intensely technical events in this community. LWN was fortunate enough to be there and able to write the following reports.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.
As usual, the summit was held in three tracks, with those tracks joining back together when issues of interest to more than one group were to be discussed.
Plenary topics
The sessions that were attended by the entire group were:
- and the future of . Persistent memory is driving a number of fundamental changes to the memory-management subsystem; one of those is the ongoing discussion of the proper role of the kernel's core memory-management data structure.
- Unaddressable device memory: the longstanding heterogeneous memory management patches are getting close to ready for inclusion.
- Handling writeback errors: the kernel's response to errors during writeback could stand a lot of improvement.
- Sharing pages between mappings; when complicated filesystem arrangements create confusion in the memory-management subsystem.
- An update on storage standards: our regularly scheduled update on what the standards committees are up to.
- Online filesystem scrubbing and repair: cleaning up XFS filesystems while they are in use (and more).
- The future of DAX: how to get even more performance out of persistent memory while keeping data safe.
Memory-management sessions
The memory-management developers discussed a number of topics in a smaller setting; these include:
- HMM and CDM: continuing the discussion of heterogeneous memory management and throwing in the complication of coherent device memory nodes.
- Slab reclaim: preventing slab-allocated objects from pinning down memory that the kernel would like to put to other uses.
- Proactive compaction: making sure that higher-order pages are available when the kernel needs them.
- The next steps for swap. Now that swapping is becoming interesting again, how do we make it perform better?
- Fast memory allocation for networking: how the memory-management subsystem can help the network stack scale to mind-bogglingly large packet rates.
- Cpusets and memory policies and the confusing things that can happen when the two are mixed.
- Supporting shared TLB contexts: what's the best way to support a SPARC processor feature that can improve the performance of some applications?
- Next steps for userfaultfd(): now that we can handle page faults in user space, what other capabilities would be nice to have?
- Memory-management patch review: why are MM patches not getting enough review, and what can be done about this problem?
The filesystem track
Topics discussed in the filesystem track include:
- Overlayfs features: As the use of this union filesystem grows, what other features should it support?
- Network filesystem cache-management interfaces: giving user space more control over how data from remote servers is cached.
- Extending : Now that the new file-information system call has been merged for 4.11, does it need extensions?
- A new API for mounting filesystems: an awful lot of functionality has been crammed into the system call; perhaps it's time to split it apart.
- Container-aware filesystems and, in particular, the handling of UID-mapping issues within containers.
- Eliminating Android wrapfs "hackery": the search for better ways to meet Android's special needs.
- Superblock watch for fsnotify; improving the scalability of the kernels file-event notification services.
- Filesystem management interfaces: ways to provide filesystem information to user space.
- A network filesystem wishlist; what Linux needs to support network filesystems properly.
- Performance problems reading files with holes: sparse files don't always perform well.
Storage and filesystem combined sessions
The storage and filesystem tracks combined for a handful of sessions of interest to both groups:
- Stack and driver testing: how can testing for low-level block components be improved?
- Inline encryption support for block devices: support for inline crypto engine (ICE) devices is needed for Android phones, what is an upstream-acceptable solution?
- Stream ID status update: the best way to provide storage with hints about the expected lifetime of the data it is managing.
Filesystem and memory-management session
There was exactly one session that crossed the filesystem and memory-management tracks:
- Huge pages in the ext4 filesystem: what will it take to get transparent huge page support into a real (storage-backed) filesystem?
The storage track
LWN's staff at the event, consisting of two people, found it strangely difficult to cover three simultaneous sessions. As a result, there is only one report from the storage track; we hope the storage group will accept our apologies.
- Booting from remote storage: the challenges associated with booting a Linux system from complex remote storage systems.
Group photo
👁 [Group photo]
[Many thanks to the Linux Foundation for sponsoring LWN's travel to this
event.]
