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

[Roman Gushchin]

"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).

>
> 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.

>
>> 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.

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.

>
>> 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 :)

>
>> 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.

Thanks