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:12:17PM +0200, David Hildenbrand (Arm) wrote:
> On 8/18/26 15:06, Lorenzo Stoakes (ARM) wrote:
> > (I'll reply to the rest of this later)
> >
> > On Mon, Aug 17, 2026 at 02:38:44PM +0100, Kiryl Shutsemau wrote:
> >> David and I talked about this at LSF/MM.  I can give it a try if it fits
> >> your idea of "feature freeze" -- and if it doesn't collide with the series
> >> you have in flight, in which case I'd rather go after yours than around it.
> >
> > Whether intended or not you sound rather like you are trying to override me
> > in favour of my co-maintainer here and it's... not helpful.
>
> I think Kiryl tried to say that we discussed at LSF/MM which areas of MM scream
> for an improvement, and we discussed that khugepaged is just horrible code.

Yes, and obviously I agree with that very much!

>
> I think we all agree that there is a lot of room for improvement, but the big
> question is:
>
> (a) When does it stop being a cleanup and is a new feature in disguise that
>     makes the code more complicated and even harder to maintain.
>
> (b) Can it just naturally be made looking like a cleanup.

Right and point (a) is exactly my pushback here.

And it's not always so easy to separate.

>
> Ideally, we'd get b), in small, nice-to-review chunks that incrementally improve
> the code without inflating it heavily or moving everything around.

Yep.

>
> The current locking is nasty, so anything that moves us one step closer into
> something that is not only simpler but also more scalable is nice. I am a bit
> concerned with the churn in the series as is.

Yes.

What I'm saying is, essentially, go read the code. Go see how coupled things
are. Go read the functions that require you to keep a giant stack of
state to even know what's going on.

Look at the bug rate, and how subtle the bugs are - essentially - 'behold the
horrors' :)

And rather than being opposed to fundamental reworks (actually - it's the exact
opposite - I think THP needs changing from top-to-bottom):

Based on experience of seeing work done in THP - we are _making it worse_ when
we add features without paying down this debt.

I think it's nuanced, because as part of reworking things (you say this below
too), patterns and approaches can fall out.

And you can naturally lead things towards a sensible rework.

>
> After this series, mm/collapse.c itself is way larger than just mm/khugepaged.c
> originally, which raises some eyebrows.

Yeah exactly.

>
> We should also be aware that people are proposing file/shmem mTHP collapse, so
> ideally what we refactor would naturally unify some of these code paths.

Right yes. There's no harm in _laying the foundations_ for future changes.

In fact a lot of reworks are about doing exactly that - you can often go one of
2 paths:

	a. push the feature in as some tacked-on thing that works but adds
	   complexity/maintainership overhhead/etc. or

	b. Change the architecture to suit the feature you intend.

So my opposition is to a, not b.

>
> I am wondering whether shmem mTHP collapse should come first. (I'm hoping that
> shmem mTHP collapse can unify some of the anon+file collapse code in a nice way,
> to similarly just look like a cleanup while enabling a new scenario. Which is
> really what I am hoping for because the current code is A MESS with weirdly
> named functions all over the place. I hope it can be unified somehow ... and
> that needs some proper thought)

Yes.

And to be clear and I am going to say this in my (proper) reply to Kiryl - I do
think moving away from the presumption of PMD collapse is _key_ to a more
general rework.

But it's about how we get there, how the rest of the code looks, what other work
we do around it.

>
> >
> > David and I co-maintain THP together, are in constant communication, and
> > have a great working relationship :)
>
> Yes! :)

:)

>
> >
> > IOW - if one of us states a position on the sub(sub?)system - then take
> > that to be the actual position.
> >
> > I have poured what must be hundreds of hours now into THP maintainership -
> > it's by far my biggest workload on the maintenance front, by far the most
> > painful and by far the most thankless.
> >
> > I do it because I care about mm a great deal and am, frankly, driven by a
> > desire to see THP turn from a flaming trash pile of a code base with
> > confusing semantics and many, many broken parts into something that serves
> > the community's needs with far less maintenance burden.
> >
> > Looking over your series it seems some of the patches works in this
> > direction (great!), but much else of it fundamentally changes key
> > behaviour.
>
> Agreed, I think we really should unify+cleanup the existing code first before
> doing more drastic changes.
>
> Having a series that throws all of khugepaged.c into a mixer and pours something
> new into collapse.c is ... concerning :)
>
> But I am sure there is a way to incrementally improve the code? At least that's
> what I hope.

Yes. And it does look like a lot of the early patches are along the right road.

I do plan to do some proper feedback on this series along the lines of figuring
out how we move this forwards.

>
> >
> > So it's just a question of deferring the latter until we get to a sane
> > point with the former.
> Thanks Lorenzo.
>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo