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

[Lorenzo Stoakes (Oracle)]

On Tue, Mar 24, 2026 at 08:24:44AM -0700, Roman Gushchin wrote:
> "Lorenzo Stoakes (Oracle)" <ljs@xxxxxxxxxx> writes:
>
> > On Mon, Mar 23, 2026 at 06:08:27PM -0700, Roman Gushchin wrote:
> >> "Lorenzo Stoakes (Oracle)" <ljs@xxxxxxxxxx> writes:
> >>
> >> > 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@xxxxxxxxxxxxxxxxxxxx> 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'll look into that.
> >
> > Thanks.
> >
> >>
> >> > 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.
> >> >
> >> > The workload is already insane, now you're expecting us to answer every bit
> >> > of nonsense Sashiko hallucinates or misunderstands also?
> >> >
> >> > I say that with no disrespect to Roman or his efforts, but as discussed at
> >> > length, it is not ready for prime time yet.
> >> >
> >> > It's clear that Sashiko is not correctly handling applies, and produces a
> >> > lot of noise. Predicating taking series on this is absurd.
> >>
> >> Not trying to pretend that Sashiko is perfect in any way, I think a good
> >> mental exercise is to put down our expectation how the "perfect" system
> >> would work. The more I work on it, the more I realize it it's far from
> >
> > Throughout this discussion I have been making practical points. Nobody
> > expects perfection.
> >
> > I am simpy saying unilaterally demanding that every single point sashiko
> > raises is responded to out of the blue without any community input or input
> > from those doing review AND requiring somehow series all apply is not
> > good.
>
> I never suggested this and explicitly wrote it below (but looks like I
> wasn't clear enough and you argue with this statement).

Yeah, Andrew has proposed this, nothing to do with you!

>
> >
> > BTW, I don't want to make you the scapegoat for complaints about mm process
> > here :) so I am being careful not to criticise, as I realise when people
> > are frustrated with tooling even if _totally irrelevant_ to you as the
> > maker of the tool, will instinctively want to blame you.
> >
> > I refuse to fall into this trap ;)
>
> Agree. Let's separate the mm process from everything else here,
> otherwise it quickly becomes too messy.

Yup :)

>
> >
> >> binary correct/incorrect. In fact, the same applies to humans: I'm sure
> >> everyone of us had once this feeling that someone is to picky and just
> >> annoying us with finding small nits. At the same time some of these
> >> people are extremely useful for the community to find and fix a lot of
> >> issues. In the end, we do argue all the time about questions/issues
> >> raised by human reviewers.
> >
> > Yes except human reviewers generally evolve over time to be pretty high
> > signal if they remain consistent, that is at least how it is in mm. Even if
> > you think points are trivial.
> >
> > Sashiko is hallucinating, it is raising irrelevant points that have nothing
> > to do with the series, it's creating responses that require serious time to
> > decode.
> >
> > I have not encountered review in mm that is even anwyhere near the ~50% hit
> > rate, rest potentialy violently wrong/wildly irrelevant that sashiko
> > generates.
> >
> > There's an asymmetry too - sashiko can just keep on generating this stuff
> > indefinitely (well, limited by tokens of course :), and potentially
> > generate serious useless work for submitters and reviewers.
> >
> > We _have_ to take that into account when it comes to review process.
> >
> > Again, this is nothing to do with the tooling which I'm grateful, again
> > it's to do with mm process. And sadly you've been dragged into a debate on
> > this which you are ultimately more or less orthogonal to :)
> >
> >>
> >> Like do we prefer a system, which finds more real bugs at the cost of being
> >> more noisy or we prefer a system which misses more but if it points at
> >> the bug, it's certainly real? I'm sure you tempted to prefer the latter,
> >> but image a hypothetical system which finds _all_ bugs, but has some false
> >> positive rate, e.g. 20%. I think it's pretty attractive.
> >
> > I think we are very far from that right now. The issue is how it is _now_
> > not in some imagined future.
> >
> > And it's easy to pontificate about all this, but in the end it's the
> > sub-maintainers in mm who will have to eventually figure out whether a
> > series is ok or not, and have to decide stuff people might do based on
> > hallucinations/irrelevant points etc.
> >
> > Right now this is going to result in _more work_ for us, and already it
> > feels like in mm the sub-maintainers are the reason things function
> > reasonably, but we don't seem to be having our voices heard here.
> >
> >>
> >> Also lot of raised issues are real, but subjectively are not worth our
> >> time. But this is extremely subjective! Depends on the personal level
> >> of perfectionism, amount of time available, the state of code before,
> >> further plans, etc etc. For example, syzkaller has usually o(100's) open
> >> bugs, which are 100% real, but not always are high priority work.
> >
> > I don't think it's anywhere near as subjective as you say, and I think
> > that's easy to hand wave.
> >
> > One issue here is - trust. There are people in the community we trust to
> > whom we asssign M: and R: entries in MAINTAINERS.
> >
> > Trust on taste, judgement etc.
> >
> > Now sashiko is essentially proposed to be given the same trust despite
> > absolutely not deserving it.
>
> I don't remember anyone ever said this, at least I definitely did not.

Andrew has said that every single point sashiko raises needs to be
addressed or patches will not be taken, that's again a separate process
issue.

>
> I think Sashiko can be really useful in finding mechanical bugs, so that
> _eventually_ maintainers can spend most of their cycles thinking about
> the direction and high-level ideas rather than checking if all gotos in
> error handling paths are correct.
>
> >
> > What I propose, as I did in the other sub-thread here, is to use it as a
> > _tool_ to _help_ sub-maintainers do their job.
> >
> > Not for it to become a new trusted gatekeeper out of the blue and
> > unilaterally while adding to our workload.
> >
> >>
> >> I think that asking to address 100% issues raised by any LLM is not
> >> reasonable (especially because it's output might be different each time
> >
> > Really, again with respect and trying to dodge the 'blame the tool maker'
> > thing :) that's something of a strawman, nobody is saying they require
> > that.
> >
> > I think >~50% signal is a reasonable ask though.
>
> I think you misinterpreted me.

Right, but this is broadly the hit rate I've experienced. It's not a
criticism, just saying that from an RoI point of view, I'd want to see that
be higher before putting in _stringent_ requirements as to having to
address points.

>
> >
> >> you runt it with the same input), but I also think it's reasonable to
> >> address critical & high severity concerns. And I'm happy to tweak
> >
> > Right, but with respect you're not an mm maintainer who has to deal with
> > the resultant fallout :)
>
> I am btw :)

Oh damn I am so sorry! That is me being a scatterbrain and not some strange
kind of insult or something :P I promise!

I was thinking of you with your sashiko hat on :)

The point of saying that was to emphasise the process side of things, and
it being separate of course.

>
> >
> >> Sashiko to be more conservative here, but I think it should be based on
> >> some specific examples or data, not purely subjective.
> >
> > Well you can't both say all review is highly subjective and simultaneously
> > ask for objective feedback :)
> >
> > I have provided detailed feedback on a specific example elsewhere, and I'm
> > telling you as an experienced mm maintainer that the hit rate is ~50% in my
> > experience so far.
> >
> > I'm happy to feedback more, but it's again a time and workload thing - the
> > default here shouldn't be that mm is just taking sashiko input as read and
> > we have to jump on everything to explicitly say it's right/wrong.
> >
> > Ideally we'd have some way of feeding back on the website, even if it's as
> > simple as a tick/cross as to what points you are actually accepting or
> > not. That'd be great I think!
> >
> > That could be useful as well to Andrew who could see that in action.
> >
> > User login wise you could have some system where somebody could send a mail
> > from the account that is being reviewed to get a login or something?
>
> This is an option. We have to agree (at least on per-subsystem basis)
> what's the best option here. For me as Sashiko developer it doesn't
> really matter which way I get the signal - I need the signal.

Right, but from a workflow point of view, it's not really workable to have
to respond to every input in any kind of detail.

So to me something super simple like tick/cross on responses would be
great.

>
> Thanks

Cheers, Lorenzo