Linux Kernel Summit: Memory Management

Next Peter Zijlstra and Mel Gorman led a memory management session. There was some discussion of variable page sizes, with Linus expressing a strong preference for continuing the hugetlbfs strategy, including allowing creation of separate hugetlbfs segments of distinct, native hardware page sizes. In other words, an administrator would create potentially a large page region of 1 GB pages and another of 16 GB pages on a platform that supported those two page sizes. Then the applications would be responsible for explicitly accessing the page regions of the appropriate size. There were several people arguing strenously for a more automated usage of various large pages sizes without requiring application awareness, such as is done in Solaris. Linus would have none of that, arguing that the complexity and maintainability of the MM subsystem would be severely compromised and there would be new and unpleasant application side effects when large pages were not available. The impacts on MM locking in general would probably ripple widely throughout the kernel. The largest concession that Linus made was that extracting common library functions from the mainline path and the hugetlbfs code to simplify maintainance would not bother him at all - a very pragmatic assessment.

The other issue that Mel confronted was that memory management workloads tend to vary widely and to be generally complex. Plus, the various MM contributors seem to be very inconsistent when requiring testing to validate a new patch or change in that area. Specifically, Mel tried to get a clear answer to what type of workload or testing would be acceptable to all in validating performance related patches against the MM subsystem. There was never a clear answer to the question, mostly with the answer "it depends" or "it depends on the patch". But no workload was validated as a "good" workload and microbenchmarks were pretty clearly not the right answer for most of the MM patches. There was an expectation that people working in this space would submit performance comparison numbers for some valid workload showing the value of the patch, but Mel responded that most workloads have been rebuffed with the response that they are not reasonable or valid workloads.

I don't think that conflict was ever resolved, and was left as an open "do the right thing" sort of response. It will be interesting to see how the next few conflicts like that are resolved on LKML or linux-mm.