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

[David Hildenbrand (Arm)]

On 3/23/26 12:19, Lorenzo Stoakes (Oracle) wrote:
> On Sat, Mar 21, 2026 at 07:12:13PM -0700, Roman Gushchin wrote:
>> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:
>>
>>>
>>>
>>> ?
>>
>> It's displayed in the Baseline section for every patchset.
>>
>> For mm patchsets if the base commit is not specified it's mm-new then
>> mm-unstable then mm-stable then linux-next/HEAD and then linus/HEAD
>> (and now I think that it should not only show HEAD, but the actual sha).
>>
>> I don't have yet support for "previous version is applied, let's revert
>> it and try the new one" case. Something to add later.
>>
>>> The way things are going at present, I'm just not going to apply a
>>> 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.
>>>
>>> Question please: if Sashiko finds an "issue" in v3 and then v4 comes
>>> out with changelog words which justifies the questionable alteration, can
>>> Sashiko parse that changelog justification and think "OK, never mind"?
>>
>> Yes, I'm planning to add it. Sashiko will have an access to previous
>> versions of the patchset and the whole discussion thread and take it
>> into the account.
> 
> Hmm this question presupposes that we should have to respond somehow to
> Sashiko feedback, but with ~50% signal vs. noise (my experience so far)
> that's just not sensible, and a painful addition to already overstrained
> workload.
> 
> For instance
> https://sashiko.dev/#/patchset/cover.1774029655.git.ljs%40kernel.org is
> full of pretty useless stuff, including a silly hallucination
> (VM_WARN_ON_ONCE() cannot be used as a conditional, it's defined as
> (void)WARN_ON_ONCE() when CONFIG_DEBUG_VM is enabled).
> 
> I don't want to have to explain why exactly I'm ignoring certain things
> each time.
> 
> Until the noise vs. signal is better, I really don't want Sashiko to block
> anything or necessitate responses, which is why I'm very reticent to see it
> send emails other than privately directly to the author perhaps.

100% agreed. It's a pain to dig through the AI output to find something
useful. Fortunately there is some useful stuff in there every now and then.

I've seen the AI either raises wrong stuff or just brings up stuff that
is completely unrelated to the actual code changes, which is quite the
time sink and TBH annoying.

Particularly annoying if review on a new revision suddenly includes new
slop.

I wish we could tune Sashiko to focus on serious regressions, and only
report them if it is extremely sure that there is something real in there.

-- 
Cheers,

David