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

[Pedro Falcato <pfalcato@suse.de>]

On Mon, Mar 23, 2026 at 02:36:04PM -0700, Andrew Morton wrote:
> On Mon, 23 Mar 2026 12:34:31 +0000 Pedro Falcato <pfalcato@suse.de> wrote:
> 
> > On Mon, Mar 23, 2026 at 11:31:29AM +0000, Lorenzo Stoakes (Oracle) wrote:
> > > On Sat, Mar 21, 2026 at 05:15:30PM -0700, Andrew Morton wrote:
> > > > On Fri, 20 Mar 2026 20:33:11 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > >
> > > > > A lot of patchsets are "failed to apply".  What is Sashiko trying to
> > > > > apply MM patches to?  It would take some smarts to apply the v2
> > > > > patchset when v1 is presently in mm.git?
> > > >
> > > > ?
> > > >
> > > > The way things are going at present, I'm just not going to apply a
> > > 
> > > 50% noise vs. signal?... maybe wait until we're in the 9x'%s?
> > > 
> > > > series which Sashiko "failed to apply".  And that's cool, I'll just
> > > > wait for a version which Sashiko was able to apply.  And then not
> > > > apply unless all Sashiko questions are resolved or convincingly refuted.
> > > 
> > > Andrew, for crying out loud. Please don't do this.
> > > 
> > > 2 of the 3 series I respan on Friday, working a 13 hour day to do so, don't
> > > apply to Sashiko, but do apply to the mm tree.
> > > 
> > > I haven't the _faintest clue_ how we are supposed to factor a 3rd party
> > > experimental website applying or not applying series into our work??
> > > 
> > > And 'not apply unless all Sashiko questions are resolved or convincingly
> > > refuted.' is seriously concerning.
> > 
> > FWIW I wholeheartedly agree. I don't understand how we don't require proper
> > M: or R: reviews on patches before merging
> 
> I wish people would stop making this claim, without substantiation. 
> I've looked (deeply) at the data, which is equally available to us all.
> Has anyone else?
> 
> After weeding out a few special cases (especially DAMON) (this time
> also maple_tree), the amount of such unreviewed material which enters
> mm-stable and mainline is very very low.

That is not what I said. I said "we don't require proper M: or R: reviews
on patches before merging". Which as far as I know is still true when it
comes to the process. If I have this wrong, then I'm not the only one.

The fact that the end result is still high quality is a result of your work
(diligently tracking down review states; yes, i've seen your quilt series file
and its annotations) and every single one involved in the review process.
This is not however codified into the process.

(note: the fact that DAMON and maple tree both lack reviews from !authors
just shows there is a very low bus factor at stake. we should fix this...)

> 
> > Like, sure, sashiko can be useful, and is better than nothing. But unless
> > sashiko is better than the maintainers, it should be kept as optional.
> 
> Rule #1 is, surely, "don't add bugs".  This thing finds bugs.  If its
> hit rate is 50% then that's plenty high enough to justify people
> spending time to go through and check its output.

I agree. But I don't think it's flawless enough to become mandatory.

> 
> > Seriously, I can't wrap my head around the difference in treatment in
> > "human maintainers, experts in the code, aren't required to review a patch"
> 
> Speaking of insulting.

Then I sincerely apologize. I see how I was brash. I did not mean to insult.

> 
> > vs "make the fscking AI happy or it's not going anywhere". It's almost
> > insulting.
> 
> Look, I know people are busy.  If checking these reports slows us down
> and we end up merging less code and less buggy code then that's a good
> tradeoff.

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.

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
  - Ideally both, but maple and DAMON need special casing for now, I guess.
 - NO -next content is being accepted during the merge window. straight to /dev/null.
 - review state for each patch is <here>

it would already be a huge, palpable win for everyone involved. Some of
these have been asked for and discussed by people that are much more
load-bearing in MM than I am, for longer than I've been around. And would
make more of a difference than making sashiko (which is not reliable,
experimental software, etc) load-bearing.

> 
> Also, gimme a break.  Like everyone else I'm still trying to wrap my
> head how best to incorporate this new tool into our development
> processes.

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.

-- 
Pedro