Re: [RFC PATCH 00/57] mm/collapse: rebuild collapse on migration primitives

On 8/17/26 15:38, Kiryl Shutsemau wrote:
> On Mon, Aug 17, 2026 at 09:52:13AM +0100, Lorenzo Stoakes (ARM) wrote:
>> 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 [email protected]?
> 
>> 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