Description
Some people say that 2026 is the year of Linux Memory Management. Others weirdly disagree.
In any case, there is plenty to discuss, as MM is as busy as ever.
We are looking for topics that would be of interest to the kernel memory-management community.
In particular, we are also interested in topic suggestions from outside the core kernel community, including userspace, drivers, architectures, and other areas that affect memory management in the kernel.
Example topics that might be worth discussing this year include:
- Making (m)THP/large folios first-class citizens
- Supporting gigabyte THPs: allocators, compaction, policies
- Better policies: applying eBPF and friends sensibly in MM
- Polishing memory reclaim: making MGLRU less special
- Ongoing challenges with memdescs conversion
- Can we make device memory less special?
- Letting the kernel manage special-purpose memory
- Improving page promotion/demotion for memory tiering
- Challenges with hypervisor live-update integration
- Towards deprecating hugetlb: mshare, memory reserves
- The future of swap: missing pieces, cleanups, and do we still need zram?
- The future of memcg: new resources, optimizations, and cleanups
- Doing more with less memory (RAM is getting expensive ...)
A microconference talk should provide enough context to enable an open discussion about the topic being presented. In particular, presentation-focused talks with little room for discussion are not what we are looking for.
-
Kevin Brodsky (Arm)
On supported configurations, the direct map is built using large
PMD/PUD-level block mappings. This is expected to bring many of the
benefits of hugepages: improved TLB hit rate, less page table walking,
smaller page table memory footprint.This optimisation is most effective when the direct map gives access to
Go to contribution page
the entire physical memory with uniform permissions. Unfortunately,... -
Will Deacon
There have been a bunch of attempts [1] to reduce the memory consumed by kernel stacks for x86 and arm64, largely based around the idea of dynamically growing the kernel stack allocation based on page faults. This poses what appear to be insurmountable challenges, as it introduces complexity into the architecture exception entry code (which needs to be able to transition cleanly to a new...
Go to contribution page -
Shakeel Butt
On a densely shared host, a routine event breaks tenant isolation: a task holding a shared kernel lock (filesystem metadata, a control-plane mutex/rwsem) allocates inside the critical section, the allocation falls into memory reclaim, and until reclaim finishes every other task waiting on that lock โ from any cgroup โ pays the stall. Shared kernel locks aren't mediated by cgroups or memcg...
Go to contribution page -
Shivank Garg (AMD), Zi Yan (NVIDIA)
As the memory hierarchy deepens at both ends, with HBM adding a faster tier on top and CXL adding cheaper, slower capacity below, keeping hot data in the fast tier and shedding cold data downward makes page migration central to NUMA, tiered-memory and coherent CPU-GPU systems (where device memory is exposed as NUMA nodes).
Profiling move_pages(2) shows the folio copy dominates (~97% of...
Go to contribution page -
Albert Esteve (Red Hat), T.J. Mercier (Google)
On embedded and automotive Linux systems, a single daemon often allocates DMA-buf memory on behalf of other clients. Today, most of that memory is invisible to cgroup accounting, only system-heap buffers can carry a charge via __GFP_ACCOUNT, and even then it lands on the allocatorโs cgroup rather than the app that requested the buffer.
The misattribution has real consequences on any system...
Go to contribution page -
Kairui Song (Tencent)
When handling swap page faults, the kernel often don't reads just a single page. For legacy HDDs, an entire cluster is read in. For SSDs, we check the VMA and page tables to see if nearby pages are likely to be needed soon, using a basic statistic-driven heuristic. For compressed RAM (like zram, and potentially soon zswap), traditional readahead is skipped entirely. Meanwhile, enabling (m)THP...
Go to contribution page -
Matthew Wilcox (Oracle)
In 2023 we introduced per-VMA locks to solve contention and priority inversion on the mmap_lock for multithreaded programs. While successful, the initial implementation did not solve every case of contention and some workloads can still demonstrate problems. This session will discuss ways of fixing the remaining problems.
Go to contribution page