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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Tue, Aug 18, 2026 at 04:15:27PM +0200, David Hildenbrand (Arm) wrote:
> 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 kas@kernel.org?
> >
> >> 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.

Ah yeah I kinda lost those but indeed doing this is a good idea.

I should try to dig those out again or look again when I have a chance...

>
> 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.

Yes and another point and I think it's one that Kiryl also gets at is - can we
_please_ stop pretending huge folios == THP == what the page cache does == page
special cases like DAX? :)

I think Matthew had ideas (TM) about separating out CONFIG_THP from that stuff
but that's another way in which we can unwend some of the horrors.

>
> This is, unfortunately, also something that needs more thought, because we don't
> want to end up moving stuff back and forth.

Yeah annoyingly it's not all straightforward. I wonder if actually gauging off
of what series often touch in patches might be a good way of figuring out how to
separate, funnily enough (certainly for mm-next conflict resolution purposes
anyway).

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo