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 A2A7423AE87 for ; Fri, 21 Aug 2026 11:16:54 +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=1787311015; cv=none; b=T11sPOtkaHngiyWZAOy59+UKztzQ+38JIznoavlNjYR3lJIbKq8XxuqCz6beyezDQlLmDHoSvO28ha+wZ/TxU6gI23WTl8tAXzHOzS7E5k68qWEEeabCd9KvQWL4Ds+hT+O5DRJ9TTexnsCyCcQ+hjzyZmOc5GI2H4Qb1U3Dlu4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787311015; c=relaxed/simple; bh=Z5RxtufTG600IBgffcj2TofRDkFheYfh9EqmORzxYAg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=j6EJW75EZx2/1DFjDD+LeZxhM40aVQNPmkgUGqcW1p6oklrVq0uj4QHV2OWXiKHGY4/yDu3JzXVGRTziJhgVu1oSVGpl5HrM0DbDYMNN0xBGwUjzfZBcNEFIekh4vU+YhYhF5qRbH4kIkrBUDZNmzBmIS4THx1EEDnhqWj8yIT4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VcysFdYC; 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="VcysFdYC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73E841F00A3A; Fri, 21 Aug 2026 11:16:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787311014; bh=KGFY8Wph74poQlCTeXTgQZO9xVvJ3OIvs0GGQOMzH3Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VcysFdYCHpmHmNN303g7tSxdzlAD5viQ7gg07COrdjH1qKdMKLD1rXDSQpIeKQG44 0HKd5IwVWfRFpcBrp6o5vtlGMKuZdnNT7qzgre0ka42vw95KdE7/3utBxu3YnlWYtD qZ0iKZbdSUA3nY/F8ZoCIDWJhXlbYtUkGcgDUQbJiB6xYpf7xOfla0Bali1PC9c3nO aTC0yVinIJMrfqwAo/Nei2J0JHb8R1eQjt5QOVakeB7Seio9MDxDTo56SfYkd2Pta0 fV55wmMRpK+zMXkW+DgqBmPMIB8ATiM5ETVaVSMLB/dYQY/elIwTrlImMAiIVr24Wl 8dRtX856/c/cA== Date: Fri, 21 Aug 2026 12:16:47 +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: On Fri, Aug 21, 2026 at 11:21:31AM +0200, Michal Hocko wrote: > On Fri 21-08-26 09:58:52, Lorenzo Stoakes (ARM) wrote: > > +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 :) > > I wouldn't blame Sashiko on this really. Yes it points to a theoretical > problem. That is fine. But we should encourage people to not blindly I mean it's not only this case, it's a pattern I've been observing for a while. > follow that lead and immediately jump at fixing something that is not a > real problem. Quite honestly I even haven't looked into patches until it > is clear that the usecase is sound. We should enforce this more and > leave patches lingering if they are not sufficiently justified. Yes this is a needed change in mm, but until we fully transition workflow any patch might still land. And I still find those kinds of suggestions deeply problematic for reviewer workload. If you had a person repeatedly say 'hey unrelated to this series but...' you'd very quickly ask them to stop and if they persisted, >/dev/null them. I get that passive passes are too expensive and it's not that much more work to have sashiko point this stuff out, but it's not that much more work for _it_, it's substantially increasing workload for reviewers. As I said on a recent call - it's fine as long as you don't care about reviewer/maintainer burnout. But I do so :) > -- > Michal Hocko > SUSE Labs -- Cheers, Lorenzo