From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-99.mta0.migadu.com [91.218.175.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F13322D8762 for ; Fri, 21 Aug 2026 21:35:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.99 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787348119; cv=none; b=UcuLixmfRQ8pAGx9PkKohC1a/2fkBSrlQk4ld9AIEOKKR3v74FMWwNztD3c2LzDDCWnnyuF9M/6raGntMPSwyDqCaT2SXEUiqGdbSpfmjuNv9p8ITNl3aCDOtAUPBa5uudmuMMXgJvXNcbH+PfEeH7/hpsIhl6qdm+8O6FrSlQM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787348119; c=relaxed/simple; bh=o8c4zF4D2sASPXDeNAkCDbQ/WUugHXEUBThuwoDLNnk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=FifU1u65DoioY5hhbSM42Kz+8pKUlk/qjk4pzUr5tvA5ennM3VZqtSqzthgaLbOErMm9eKyK/X4PaYLwDb9khup+bpeNGflj+bXraGR9kuR9OHeXY8irqWsSgy7z4B/vUghYJUVAzdpsrwn27z8++Stm+eyGt80C4nyxqto5Kh8= 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=HLAC3vTl; arc=none smtp.client-ip=91.218.175.99 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="HLAC3vTl" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=o8c4zF4D2sASPXDeNAkCDbQ/WUugHXEUBThuwoDLNnk=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787348113; v=1; x=1787952913; b=HLAC3vTlZSKWH6d+79LfitBu65Z7UoiAqNK2Tp/f19hvsa61rPgk63oCMneCGlCKALnXqjya mps/5lHNLtjCU2Z/YJIY0HVdYeVXObjTg/rABSmbsfq1umwVhOsLC2Dyn20U8nZjX100nv899Wj bh6mreEIK2V99n7vcc5ma7tM= X-Envelope-To: linux-kernel@vger.kernel.org Received: from castle.c.googlers.com (35.203.187.139) by mta12.migadu.com with ESMTPS id e805eb4d6b971688; Fri, 21 Aug 2026 21:35:08 +0000 X-Mizu-Trace-ID: e805eb4d6b971688 X-Migadu-Flow: FLOW_OUT From: Roman Gushchin To: "Lorenzo Stoakes (ARM)" Cc: Michal Hocko , 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 Subject: Re: [RFC PATCH 0/4] mm/vmscan: honour node reclaim limits per type In-Reply-To: (Lorenzo Stoakes's message of "Fri, 21 Aug 2026 09:58:52 +0100") References: <20260821081741.1340277-1-ridong.chen@linux.dev> User-Agent: mu4e 1.12.15; emacs 30.2 Date: Fri, 21 Aug 2026 21:35:04 +0000 Message-ID: <7ia4tsonw41j.fsf@castle.c.googlers.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Lorenzo Stoakes (ARM)" writes: > +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. I thought about it, but switching it off completely looks dubious to me. So maybe moderating it a bit can help? Like not reporting completely unrelated issues or at least do not report them more than once? Even if it's only 50% accurate, 50% chance of missing a critical/high severity bug (other are not reported) sounds bad. But also I feel like there should be no expectations on fixing pre-existing issues as something _required_ to land a patch. It's always a best effort thing. > Maybe we could figure out a way of funnelling this stuff somewhere separately > longer term. Yes, there will be a database available to maintainers soon. > > (I have I think 2 slopped fixes to rewrite after the previous what like 7 or 8 > this cycle? So forgive the grumpiness :) No problems :)