Re: [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd()

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

On Mon, Mar 23, 2026 at 05:05:37PM -0700, Andrew Morton wrote:
> Well, I looked at some numbers.  Data!
>
> Searched for linux-mm emails which had from:akpm, message-body contains
> "sashiko".
>
> 22 emails received replies from authors indicating that alterations
> were needed.
>
> 2 emails received replies from authors indicating that no alterations
> were needed
>
> 1 email received a reply from author in which I wasn't able to decide
> either way.
>
> A few more replies said "no alteration, but we need to change other
> code".
>
> 10-15ish have yet to receive replies.
>
>
> That's a really high hit rate!  How can we possibly not use this, if we
> care about Rule #1?

Really this data doesn't support that.

If we're generous and say 10 with no replies, that's 22/35 or ~63% _where
sashiko was correct in AT LEAST ONE individual observation_.

That is not indicative of a good signal-to-noise ratio.

Do you not think we can do better?

Roughly in my experience, around ~50% of sashiko INDIVIDUAL REPORTS
(i.e. individual comments made line-by-line) have validity.

Roman has said that the strategy he takes, partly for sensible token usage,
partly to avoid throwing out the baby with the bath water, at this time
leads to more noise. And as models improve this is likely to also.

This is no criticism of him, I am grateful for this tooling.

The issue is with mm process.

This adds quite a burden to reviewers to have to deal with _every single
thing_ reported.

Which is what you unilaterally seemed to say was now a requirement, to
which I object.

There's further problems here:

1. What if a new engineer comes along and sashiko hallucinates a bunch of
   stuff and they respin + respin to match it, and now reviewers have to
   tell them to stop?

2. What if sashiko directly contradicts a human reviewer/maintainer?

3. Are you going to quietly just not take series and people find out in the
   merge window/when you gather up mm-stable in one of the many batches,
   because they didn't respond to a hallucination?

4. AI often generates new 'thoughts' just from being ran for a 2nd time, so
   do we hold series in perpetual flux trying to figure out if the latest
   set are valid?

5. Often the reported 'issues' are so complicated it requires human
   expertise to figure out if they're relevant, thereby increasing the
   already over-strained maintenance workload.

And again, I come back to you requiring sashiko to be able to apply a
series, based on unknown criteria, probably not correctly apply fix-patches
etc. - there is no sensible way for a series author to fulfill that
requirement.

Really we need input of _those doing the actual review_ in how mm review
works.

Let me make workable suggestions:

1. Defer this to sub-maintainers. We have the expertise and experience to
   make judgment calls on this.

2. Don't make this silly series applies demand. It's impossible to adhere
   to.

3. Don't require that every sashiko point be responded to.

4. Sub-maintainers use it as a tool - and only really consider
   critical/high bugs as being potentially important, and only if they can
   determine that the points made are valid AND importantly - only if doing
   so doesn't take all that much time.

Personally I am _already_ using sashiko as part of review for people to
some degree. I see that as being the more useful means of using it.

Treat it as the experiment it is, rather than reflexively deciding to
demand all points get responded to.

>
> > Sure. But I'm thinking about the human factor - I simply don't think either
> > contributors or maintainers will be particularly less stressed with the
> > introduction of obligatory AI reviews. Maintainers are still hardpressed
> > to review (as is their function), and contributors need to go through the
> > tool's output and figure out what's relevant (and _true_) or what's not.
>
> Yeah, it's a matter of figuring this out as we go along.  It will be so
> much better if/when people are able to use sashiko privately.  But
> heck, people forget to run checkpatch ;)

But we're not 'figuring it out', you're not discussing anything with
sub-maintainers or the community, you're unilaterally telling people they
HAVE to respond to everything sashiko says or you WON'T TAKE the patch.

And also (you ignored my reply on this and replied to Pedro instead)

So where's the figuring out exactly?

>
> > IF we were able to codify the MM process like in (https://docs.kernel.org/process/maintainer-netdev.html),
> > with things like:
> >  - NO patch is getting in without being 1) written by a maintainer or 2) getting Rb's and Acks from M's and R's
>
> Sure.  Where "in" means mm-stable.

I'm not sure anybody said otherwise??

>
> >   - Ideally both, but maple and DAMON need special casing for now, I guess.
>
> We do get quite a lot of patches from sole maintainers.
>
> >  - NO -next content is being accepted during the merge window. straight to /dev/null.
>
> For sure.  Well.  I usually park these thing to take a look at after we're all
> merged up, but it's usually all stale by then.
>
> >  - review state for each patch is <here>
>
> I generate that now, with the occasional "mm.git review status" emails.
> I could run it daily and add it to mm.git or something, but this
> doesn't seem to have generated much interest.
>
> > I understand. Ideally, sashiko would be a tool that maintainers and
> > reviewers (and submitters) could use to help find problems. I don't think
> > having you check every AI review scales. But I also don't think we should be
> > treating LLM output as if it were a normal review from an expert.
>
> Sure,  But that hit rate is so high!

Addressed above. Disagree.

Please listen to the people doing the actual review in mm.

Thanks, Lorenzo