From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 7B1363CF680 for ; Fri, 21 Aug 2026 08:58:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787302740; cv=none; b=l7EzcudshqzTUpKoSb2n5n6L+zsRlcsqCeuRia+u+QX7is5a9A/OYoeRExXUee8qZQSa81LaNPXdSWSrM0GakCzbrKZf/5A7m9vReSlAUrYSPPe5evKQxo//SBiQoOqERMdyawQNfxYidpUnQO2ZzkSPQJmZpkFFuB1XIhQ+TYE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787302740; c=relaxed/simple; bh=eEuCKKLfpd4XG5hcGGzWCMxZNtTwXKUvDPR7o5Lq3kA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pbYFKqZiNqaMQWXGJtkM26yFOPbKpPrZxhKmgy8nOOIFmKZBbI2vuJdj0rMWDrN3nacl7LW1m/ZfODPEXbewnXr3YRQWBhNPukyBcIjFijn6WRSa/+ITF7MAB6vD75MFzuotK9pFNx3uw3tnweYPEjZB7cMCKr+pRsY5yRhfLxI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NVgG0YWk; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NVgG0YWk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35A3B1F00A3A; Fri, 21 Aug 2026 08:58:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787302739; bh=/svEZ96u/XgpDcn+/+8Lk9kAWvGHG4PXL4nB1no2kT0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=NVgG0YWkXKLHdVuOJkonzqIhIVR2HYmY/jEGmlu1+tTGtqx5zpcNbIMqgc9EpYLAp lISq+kipsOgr1sgA2POu6j+GyAbz1wYUe1h4Wiir1F3gNYEw0Z2T+oBZCEzJfWWhTp Q4skTFdto/yRNMaVUvCbswuz3oltufek1wfE+q788FZbXIdERyBh1ex3jK5+3FHtyj zJ+5UjLmIdadRJ691Nxo9bmI9DfmwCnfnhaFwTqIujf9zTlS7YoPp6SqSDJQn1LmM6 a8p5S8RXsQd9ilwC5O4LH/JYTz4vfNte76y8Yx2poGDWIZ/1Cr68s9Cu3Mo4yYUaxZ hopwQha8dTCYw== Date: Fri, 21 Aug 2026 09:58:52 +0100 From: "Lorenzo Stoakes (ARM)" To: Michal Hocko Cc: Ridong Chen , Andrew Morton , Johannes Weiner , David Hildenbrand , Qi Zheng , Shakeel Butt , Kairui Song , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ridong Chen , Roman Gushchin Subject: Re: [RFC PATCH 0/4] mm/vmscan: honour node reclaim limits per type Message-ID: References: <20260821081741.1340277-1-ridong.chen@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: +cc Roman for suggestion. On Fri, Aug 21, 2026 at 10:31:06AM +0200, Michal Hocko wrote: > You are explaining what but missing the most important part _Why_ do we > need to have this addressed? Is this just addressing Sashiko review > refernced below? Is there any real usecase where the current behavior > matters? This is exactly the issue with these 'unrelated to your patch but' suggestions from sashiko. You end up in loops: AI generated patch ---------------> AI generated review ^ | | | | v AI generated 'unrelated to your patch but' And _at every stage_ reviewers have to do _additional work_ (with ~50% signal/noise). This isn't sustainable. We already had _too much work_ prior to the slopgeddon. Now we have a multiple of that. Roman - I really think we a way of switching off the 'unrelated to your patch but' stuff per-subsystem would be useful. Maybe we could figure out a way of funnelling this stuff somewhere separately longer term. (I have I think 2 slopped fixes to rewrite after the previous what like 7 or 8 this cycle? So forgive the grumpiness :) -- Cheers, Lorenzo