From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8338E40245C for ; Tue, 24 Mar 2026 15:24:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774365899; cv=none; b=pdwHZ6fEDx0JEXkykjUgbBcB//ioM/bCpN1LM8jyU8jX2GQFPoj1t5E3wwswkO1OZTI01FAFND+AUNiArYCjps4uHwqqzY88Rwc/tt5hTCFCRUABKQ7QOlYzASPlP1wKxTud2kaKLe3eKjK4PC748/DuXxBqH9dgI0vn1+KXfhE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774365899; c=relaxed/simple; bh=JT9WpQYQSyW7CijyVaJg47iofEjjLgnALX5Z5lvbvow=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=EEwAT+yrt3703J4y5Oh9tR25rNomffN+wA3cUKNpBTXAIb0l23C4icjVtE0LdbNB83pmEsirgxl9MYzIe9In9AZA5wJIW9U5a+Kb3If2UVyt8Xd9HBBeuFL41cehggIoolCisbIXYEVqs8SYLMYJuCriBz/LzcwYghlw01PnfVQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=PnzdZ+TJ; arc=none smtp.client-ip=91.218.175.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="PnzdZ+TJ" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774365895; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1HeiVvUHmOuUxiXDJ09SqoCM8eo8Ym5lTpx7hzcjszs=; b=PnzdZ+TJ3xnLKhHei33mdDQY8JB196kS9kEXgLCLUcaiPnd4LR9CR/CdH69RDRPIbNqCzl y245IoNZJMjbSD9ci6tGA4o7A2mXswEUbYAonsmtXLZb8ULmpL1YsVww+obLOrYOkI5dvT oE4/gW/duHtLaLzpMBh3OefBWcM+9EI= From: Roman Gushchin To: "Lorenzo Stoakes (Oracle)" Cc: Andrew Morton , David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd() In-Reply-To: (Lorenzo Stoakes's message of "Tue, 24 Mar 2026 07:56:19 +0000") References: <20260319200917.ce345a369d035050b6329ac5@linux-foundation.org> <87tsu9kgv3.fsf@linux.dev> <20260320203311.715ed75bcd84c18d24894324@linux-foundation.org> <20260321171530.8b3e8207f89d5a7384b9f01f@linux-foundation.org> <5cd57c69-7193-422f-b6b5-75bb5234e5f3@lucifer.local> <87jyv2hw50.fsf@linux.dev> Date: Tue, 24 Mar 2026 08:24:44 -0700 Message-ID: <87qzp9mern.fsf@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT "Lorenzo Stoakes (Oracle)" writes: > On Mon, Mar 23, 2026 at 06:08:27PM -0700, Roman Gushchin wrote: >> "Lorenzo Stoakes (Oracle)" 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 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