From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D9C191A2C0B for ; Mon, 23 Mar 2026 11:19:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774264748; cv=none; b=Rt9tb2yT1WCqAro6+V5W4mma/R24o8aSkY1uEceLfkJlnGh6BQyfiqVLzvwT+J3Vb6PD8IF8z+pb5UzjO6afUrq3BdjHG2nKhaoZt9uQzgqHP+j2lGQkop1QpcW/uYmrwP7dQypF1GX6wx0z1VBHq9DXMzbPF53d67dm07W1MLU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774264748; c=relaxed/simple; bh=BUqjb6fmX3WdXilimCcafolqV7S3bcE2u0WTIz11DcA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=U/DwJ1nW2Gqx3UoeDJ3Z1+PbFpHz3UmC/hNLhnWttF9Qu2iitjQbR7EUqMj/O307IGOSf9UNKBwss2vsbtHtDZmC5ppn+6BsooLhDJfpEb/6EnQpm9niuWuQE1fImxwMenU05PoXPyeEc/MIOHpME4lIUL0v0wrR3warfPk8xf8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QVvJUll0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QVvJUll0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7CFAC4CEF7; Mon, 23 Mar 2026 11:19:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774264748; bh=BUqjb6fmX3WdXilimCcafolqV7S3bcE2u0WTIz11DcA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QVvJUll0uWdgpoCICr7sQ+hes8Dj7dvNlp+oSyAkvurpEuMYy7tni48HEidifWyrx 2tS1bibdfoVjJXvA4gWHkvlL2WqmMtaIu9EPmjPZgEr3P6Tgw+3EN0gOpX5kcny/KE fBHBu3py2JWpmfh25uZFh7giDQSFBTv/33nEs9y51EyE6jP01nmiSBtzEv7+hcYwh5 xbY0wYrCEoYvKHHIOnZM+a/d9Fn+/r6U8h2WCtSTADaZ880m6H0DQRRHz2mPsG9r9u ptYHxjE6jfPVCQLJ2Pbh08IN8OO4zFIlbpoS6JlM7YUQ5kBngQInEwju9EDzVBlgfg IW0YpKltmjcUg== Date: Mon, 23 Mar 2026 11:19:06 +0000 From: "Lorenzo Stoakes (Oracle)" To: Roman Gushchin 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() Message-ID: <3d6cca25-75ff-434a-b210-114451f8dbaf@lucifer.local> References: <20260319200917.ce345a369d035050b6329ac5@linux-foundation.org> <87tsu9kgv3.fsf@linux.dev> <20260320203311.715ed75bcd84c18d24894324@linux-foundation.org> <20260321171530.8b3e8207f89d5a7384b9f01f@linux-foundation.org> <877br4k3ya.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; charset=us-ascii Content-Disposition: inline In-Reply-To: <877br4k3ya.fsf@linux.dev> On Sat, Mar 21, 2026 at 07:12:13PM -0700, Roman Gushchin wrote: > Andrew Morton writes: > > > 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? > > > > ? > > 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. > > Thanks! Thanks, Lorenzo