Re: Process (was Re: [PATCH mm-hotfixes-unstable v18 00/14] khugepaged: add mTHP) collapse support

[Lorenzo Stoakes]

On Tue, Jun 02, 2026 at 01:20:07PM +0200, David Hildenbrand (Arm) wrote:
> On 6/1/26 18:16, Lorenzo Stoakes wrote:
> > On Mon, Jun 01, 2026 at 05:45:30PM +0200, David Hildenbrand (Arm) wrote:
> >> On 6/1/26 17:41, Lorenzo Stoakes wrote:
> >>>
> >>> I think life will be easier with submaintainer separate trees for this honestly
> >>> :) or it could become a horrible mess in one tree I think.
> >>
> >> Requiring contributors to submit stuff targeted at some random trees is madness :)
> >
> > Err what? The 'random' tree is the MAINTAINERS entry you are targeting, it's
> > based on the mm-next stable branch and only diverges in the work that's been
> > done specific to the subtree, what's crazy exactly?
>
> We'll still have plenty of patch sets that touch files cross trees.

I'm not sure how keeping things in the same tree fixes anything though?

You are just changing the _timing_ of when the conflicts happen at the cost
of making things way more difficult to manage IMO.

I mean the reductio ad absurdum argument is why isn't all of linux in a
single git tree? :)

If what you're saying is true it should be without issue? But I think there
would be pretty huge issues...

And the disadvantage is now we have a bunch of sub-maintainers with write
access to the key mm tree who could make mistakes and break things,
hundreds of topic branches all bundled together, no separation between
anything, and no sense of where anything's at.

If you're saying submaintainers manage topic branches (this cycle the ONE
tree would have ~400 topic branches right? More if we included versions?)
and then independently merge those into the mm-stable tree I think that's
going to be a disaster in terms of timing/conflicts/etc.

And you're asking for conflict between submaintainers I think - what if one
person merges his thing that then causes conflict for another etc. etc.

With separate trees then decisions can be made by the mm core people as to
how to integrate, rather than people unilaterally doing whatever.

And if you're saying submaintainers won't do that, then essentially you're
saying no submaintainer tree management at all :) which I think is a a bad
idea for a subsystem as busy as mm.

I think mm is too large now to have everything under one person or a few
people.

Separate trees implies division of labour, and then the integration tree
can be more of a pure integration tree.

>
> I don't see the problem of sending stuff against the integration tree from where
> it can just be cleanly picked up by sub-maintainers (after all, that's where all
> the subtrees were integrated against)? Or what exactly is the problem with that?

But what does 'picked up' mean? See above re: concerns.

>
> This is likely something we'll have to play with to understand what is workable
> and what not.

Actually, I think we have to decide early - because if you want
submaintainers to test out this sub-tree or sub-branch? Or whatever thing
it's very different asking them to:

- Create a new tree and do X, Y and Z to sync up with mm-next

Vs.:

- Have full write access to mm-next and create branches X, Y and Z and
  merge things

>
> >
> > I mean, is there any meaning to separate 'trees' at all if we just have one tree
> > with topic branches in?
> >
> > Or are we going to have several parallel stable branches in one tree, and a
> > bunch of maintainers with write access stepping on each other's toes?
>
> All valid question to which we don't have an answer yet. :)

:) I mean learning from how others do it is definitely key here.

Maybe we need to grill Brauner?

>
> >
> > That sounds a lot more crazy to me, and I just don't think it's workable.
> >>
> >>>
> >>> I think the simplest is what I suggested in reply to Vlasta, where each
> >>> submaintainer tree has their own set of changes against mm-next/mm-stable and
> >>> then we merge each week.
> >>
> >> Throw in hotfixes and it already starts being crazy.
> >
> > Again I really don't understand this?
> >
> > Hotfixes are a completely separate topic for one, I'm talking about ordinary
> > development, but surely they're simpler aren't they?
>
> I mean the interaction: new material that depend on hotfixes. Talking to Michal
> and Vlastimil last week, there are some ways to make this work based on topic
> branches (hotfixes being a topic branch IIUC), but I don't understand yet how
> that works in detail, or how that would scale to subtrees.

OK, yes we would definitely need to have the hotfixes applied effectively
as if they were merged in Linus's tree I think underneath other things.

>
> >
> > Everything's based on Linus's tree (so no confusion as to which tree), there
> > shouldn't (hopefully) be a huge amount of them, and submaintainers can just
> > potentially find a way to send them direct to mm-next anyway?
> >
> >>
> >>>
> >>> But am open to learning about what other subsystems in the kernel do...
> >>
> >> The TIP tree has a pretty elaborate model of dealing with topic branches, and
> >> don't require things to be sent against specific topic branches.
> >>
> >> I'll try to understand that model.
> >
> > OK well, interested to hear about that.
> >
> > But also we should adapt what others do (which I think is very important to
> > learn from obviously) against how mm works in practice.
> >
> > High review load with many overlapping changes might favour a different approach
> > to a subsystem that looks different from that.
> Yeah, but as we said, we discussed, it's all rather complicated and we should
> move incrementally.

Yup, but some things have to be decided early I think. We can roll back
decisions, but some are more costly to roll back than others.

>
> --
> Cheers,
>
> David

Thanks, Lorenzo