Re: [PATCH 0/6] mm: preparatory patches for PMD level swap entries

[Lorenzo Stoakes <ljs@kernel.org>]

+cc Mike re: CI.

On Wed, Jul 01, 2026 at 04:46:13PM -0700, Andrew Morton wrote:
> On Wed, 1 Jul 2026 09:04:33 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:
>
> > On Tue, Jun 30, 2026 at 12:50:24PM -0700, Andrew Morton wrote:
> > > On Tue, 30 Jun 2026 09:34:37 -0700 Usama Arif <usama.arif@linux.dev> wrote:
> > >
> > > > This is the preparatory part of the PMD page table swapin work.
> > >
> > > Thanks.
> > >
> > > This comes reasonably reviewed, so I'll queue it in mm-new.
> > >
> > > Why?
> > >
> > > - Human review coverage and AI review make me believe this isn't the
> > >   final version at all, but I do believe this is something we want in
> > >   7.2, and getting it under test early will help to push it along.
> > >
> > > - Getting it in there early means that others will base their work on
> > >   material which will probably be upstreamed this cycle, so this gives
> > >   them a more accurate base against which to work.
> > >
> > > Sashiko did find a lot to talk about, some of it pre-existing so can
> > > people who work on this code please take a look at
> > >
> > > 	https://sashiko.dev/#/patchset/20260630164143.1595669-1-usama.arif@linux.dev
> > >
> > >
> >
> > Hm, my understanding was that mm-new is where we take everything submitted for
> > early testing?
> >
> > Did something change?
>
> mm-new has always been a few day front-end to mm-unstable.  To protect
> linux-next from brand new material.  It serves no other purpose.

Well it only serves a purpose if it gives us better testing.

We have a CI running tests now though, Mike - is that predicated on material
being in mm-new or does it just grab the email?

If the CI is just grabbing email I wonder whether there's much purpose in the
mm-new branch at all.

>
> Almost.  I'll very occasionally use it for short-term not-for-upstream
> playthings.
>
> > Generally anything submitted early in the cycle is expected to land in the cycle
> > unless there's significant adverse review or other reasons it can't be taken.
>
> Yup.  Don't want anything in mm.git which isn't expected to be
> upstreamed in the next merge window.
>
> Nowadays I'm reluctant to add anything which hasn't had a decent scan
> from reviewers.  If it's something I'd particularly like to get
> upstreamed I'll very occasionally add it early, to help push it along.

Well the question is what is considered to be a decent scan from reviewers?

Is it tags on all patches? As a glance at mm-new suggests otherwise.

I guess moving forwards with mm-next we can figure out the rules specifically on
this kind of thing.

Maintainer signoff is the key indicator of something being acceptable for the
cycle.

But I think probably if we have a topic branch of stuff we're considering for
upstream (but not the stable branch which should require maintainer signoff), a
good proportion of tags (and review from everybody matters and is important)
maybe should be the metric.

I am wondering about my series(es) in general though as I'm likely to cause
some significant merge conflict pain for people if that's delayed too
much. But sure we can wait for more review coverage on that I guess.

Thanks, Lorenzo