Re: [RFC PATCH 00/57] mm/collapse: rebuild collapse on migration primitives
From: "David Hildenbrand (Arm)" <david@kernel.org>
Date: 2026-08-18 14:15:38
Also in:
bpf, linux-kselftest, linux-mm, lkml
On 8/17/26 15:38, Kiryl Shutsemau wrote:
On Mon, Aug 17, 2026 at 09:52:13AM +0100, Lorenzo Stoakes (ARM) wrote:quoted
We have a THP cabal meeting every couple of weeks where it would have been useful for you to raise this first.Fair -- though my invite is on my old @linux.intel.com address. Could you forward it to kas@kernel.org?quoted
In any case - this series is not something we'd consider at the moment, even broken into parts. David and I have put THP into feature freeze - until the codebase is subtantially improved we're not really interested in seeing significant development. The technical debt is substantial and has to be paid down first. See [0] for a rough list of TODOs in this regard.I read the TODO list and I'll pick from it -- though I notice the technical debt section includes "Literally all of the code in mm/huge_memory.c and mm/khugepaged.c", which I'd argue this series is a fairly committed attempt at :) One clean up I wanted to do is consolidate code by functionality, not by the THP/non-THP split. Move all page fault handler code into mm/fault.c, unmap code into mm/zap.c, fork's copying into mm/fork.c -- mirroring kernel/fork.c, so the mm half of a subsystem sits under the same name. Large folios are an integral part of mm nowadays and I don't think we benefit from keeping THP in a separate file. It is also an opportunity to shift away from mm/memory.c being a kitchen sink. David and I talked about this at LSF/MM.
Ah, I missed the context in my other reply. Lorenzo already had some patches at some point to split up mm/memory.c into better chunks that will also better help our subcomponent maintenance model. I think the challenge is how to handle huge_memory.c, because ideally, we'd not have these stupid callbacks into huge_memory.c once we make PMDs just a first-class citizen. This is, unfortunately, also something that needs more thought, because we don't want to end up moving stuff back and forth. -- Cheers, David