A new era for memory-management maintainership

Ready to give LWN a try?

With a subscription to LWN, you can stay current with what is happening in the Linux and free-software community and take advantage of subscriber-only site features. We are pleased to offer you a free trial subscription, no credit card required, so that you can see for yourself. Please, join us!

Morton started by observing that he had received almost no responses to his announcement. That was, he suggested, a result of the fact that he was asking others to take on more responsibility in the subsystem; developers are going to have to pick up a lot of tasks.

How that work can be spread out is an open question. There are 164 C files in the kernel's mm directory; a quick search shows that terms like "THP" (transparent huge page), "cgroup" (control group), and "NUMA" each show up in a large number of those files. The core memory-management concepts, in other words, are widely spread throughout the subsystem. Moving code around might help a bit, Morton said, but not much; everything is heavily interlinked, so trying to split up the subsystem will be challenging. But, he noted with a smile, "it's not my problem".

Regardless of how successful a split is, there will always be a need for a catch-all tree serving the subsystem as a whole. The management of that catch-all and integration tree will be picked up by David Hildenbrand; Morton offered his thanks to Hildenbrand for taking on that responsibility.

The memory-management developers (and those for the kernel as a whole), he said, have many layers of defense to prevent the shipping of bad code to users. The community can put out random stuff, but it goes through weeks of testing in the -mm tree, followed by more weeks of testing after landing in the mainline kernel. Fixes can be backported into the stable kernels for years, and distributors provide further layers of assistance. More recently, Sashiko, by providing a new level of patch review, has become yet another layer of defense.

Developers should, he said, recognize that they are not creating production-quality code at the outset; they are creating a technology and letting others turn it into products. All of the layers of defense allow developers to pursue an "aggressive rate of change". There is a downside to that change rate, though: it puts a lot of pressure on reviewers. Within the memory-management subsystem, the review work is quite lopsided, in that a small number of people do the bulk of the review, while many developers do not carry much of the review load at all. He does not understand why things work that way, and wishes that the situation could be improved.

The memory-management team, he said, is a great group of people; they are cooperative and quick to help each other. He worries, though, that the community could, over time regress to be like other parts of the kernel or other open-source projects, where emails are ignored because maintainers are too busy. Ignoring messages from contributors, he said, is shameful and unacceptable. But, he thinks, the memory-management community does value its culture and will work to maintain it.

Matthew Wilcox said that, when somebody asks him how to get started within the community, he always encourages them to start reviewing patches. That advice is often not taken, though. He added that, while he tries to respond to email, there are days where he is simply unable to reply to all of the messages that have shown up. Dan Williams said that the community has long depended on Morton to apply pressure when responses are needed; Hildenbrand and others will need to apply that pressure in the future.

Hildenbrand responded that there will always need to be somebody who makes sure that people are doing their part; that's part of what makes the subsystem great. The level of developer frustration within memory management is lower than in many other subsystems. He worries a bit about the onset of LLM-based review tools, though. Everybody agrees that there is a need for more human reviewers, so he thinks that reviews from tools like Sashiko should not be posted to the public lists. Early-stage reviewers, who are just learning their way around, will be demotivated by seeing that automated reviews have already found many of the problems. Automated review, Hildenbrand said, should be one of the last lines of defense, not the first.

Liam Howlett said that sending LLM-based reviews to one-off contributors can have the effect of validating bad ideas; a number of participants suggested that these tools are good at finding bugs, but less good at addressing the question of whether a given change should be made at all. Morton said that beginning reviewers often focus on understandability issues that more experienced developers will skip over; that, too, is important feedback.