All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Gushchin <roman.gushchin@linux.dev>
To: "Lorenzo Stoakes (Oracle)" <ljs@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 David Hildenbrand <david@kernel.org>,  Zi Yan <ziy@nvidia.com>,
	 Baolin Wang <baolin.wang@linux.alibaba.com>,
	 "Liam R . Howlett" <Liam.Howlett@oracle.com>,
	 Nico Pache <npache@redhat.com>,
	 Ryan Roberts <ryan.roberts@arm.com>,
	 Dev Jain <dev.jain@arm.com>,  Barry Song <baohua@kernel.org>,
	 Lance Yang <lance.yang@linux.dev>,
	 Vlastimil Babka <vbabka@kernel.org>,
	 Mike Rapoport <rppt@kernel.org>,
	 Suren Baghdasaryan <surenb@google.com>,
	 Michal Hocko <mhocko@suse.com>,
	 linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd()
Date: Tue, 24 Mar 2026 08:24:44 -0700	[thread overview]
Message-ID: <87qzp9mern.fsf@linux.dev> (raw)
In-Reply-To: <bc42fdda-6be2-46ef-bec5-1ae82092f61b@lucifer.local> (Lorenzo Stoakes's message of "Tue, 24 Mar 2026 07:56:19 +0000")

"Lorenzo Stoakes (Oracle)" <ljs@kernel.org> writes:

> On Mon, Mar 23, 2026 at 06:08:27PM -0700, Roman Gushchin wrote:
>> "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> 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@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'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


  reply	other threads:[~2026-03-24 15:25 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19 13:00 [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd() Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 1/9] mm/huge_memory: simplify vma_is_specal_huge() Lorenzo Stoakes (Oracle)
2026-03-19 16:52   ` Kiryl Shutsemau
2026-03-19 17:16     ` Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 2/9] mm/huge: avoid big else branch in zap_huge_pmd() Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 3/9] mm/huge_memory: have zap_huge_pmd return a boolean, add kdoc Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 4/9] mm/huge_memory: handle buggy PMD entry in zap_huge_pmd() Lorenzo Stoakes (Oracle)
2026-03-20  3:20   ` Baolin Wang
2026-03-19 13:00 ` [PATCH v2 5/9] mm/huge_memory: add a common exit path to zap_huge_pmd() Lorenzo Stoakes (Oracle)
2026-03-20  3:27   ` Baolin Wang
2026-03-19 13:00 ` [PATCH v2 6/9] mm/huge_memory: remove unnecessary VM_BUG_ON_PAGE() Lorenzo Stoakes (Oracle)
2026-03-20  3:31   ` Baolin Wang
2026-03-19 13:00 ` [PATCH v2 7/9] mm/huge_memory: deduplicate zap deposited table call Lorenzo Stoakes (Oracle)
2026-03-19 17:03   ` Kiryl Shutsemau
2026-03-19 17:18     ` Lorenzo Stoakes (Oracle)
2026-03-19 21:56       ` Kiryl Shutsemau
2026-03-20 13:59         ` Lorenzo Stoakes (Oracle)
2026-03-20 14:14           ` Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 8/9] mm/huge_memory: deduplicate zap_huge_pmd() further by tracking state Lorenzo Stoakes (Oracle)
2026-03-20  3:49   ` Baolin Wang
2026-03-20 13:51     ` Lorenzo Stoakes (Oracle)
2026-03-21  5:15       ` Baolin Wang
2026-03-19 13:00 ` [PATCH v2 9/9] mm/huge_memory: have zap_huge_pmd() use vm_normal_folio_pmd() Lorenzo Stoakes (Oracle)
2026-03-20  3:09 ` [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd() Andrew Morton
2026-03-20 13:27   ` Lorenzo Stoakes (Oracle)
2026-03-21  3:21   ` Roman Gushchin
2026-03-21  3:33     ` Andrew Morton
2026-03-22  0:15       ` Andrew Morton
2026-03-22  2:12         ` Roman Gushchin
2026-03-23 11:19           ` Lorenzo Stoakes (Oracle)
2026-03-23 11:24             ` David Hildenbrand (Arm)
2026-03-23 11:31         ` Lorenzo Stoakes (Oracle)
2026-03-23 12:34           ` Pedro Falcato
2026-03-23 21:36             ` Andrew Morton
2026-03-23 23:27               ` Pedro Falcato
2026-03-24  0:05                 ` Andrew Morton
2026-03-24  7:35                   ` Lorenzo Stoakes (Oracle)
2026-03-24  7:58               ` Mike Rapoport
2026-03-24  9:55                 ` Lorenzo Stoakes (Oracle)
2026-03-24  1:08           ` Roman Gushchin
2026-03-24  7:56             ` Lorenzo Stoakes (Oracle)
2026-03-24 15:24               ` Roman Gushchin [this message]
2026-03-24 18:05                 ` Lorenzo Stoakes (Oracle)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87qzp9mern.fsf@linux.dev \
    --to=roman.gushchin@linux.dev \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=lance.yang@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=npache@redhat.com \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.