From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outbound-smtp30.blacknight.com (outbound-smtp30.blacknight.com [81.17.249.61]) (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 3148429CA for ; Mon, 6 Dec 2021 11:33:59 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp30.blacknight.com (Postfix) with ESMTPS id D0FDFBAF29 for ; Mon, 6 Dec 2021 11:25:47 +0000 (GMT) Received: (qmail 7725 invoked from network); 6 Dec 2021 11:25:47 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.17.29]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 6 Dec 2021 11:25:47 -0000 Date: Mon, 6 Dec 2021 11:25:45 +0000 From: Mel Gorman To: Shakeel Butt Cc: Andrew Morton , Michal Hocko , Vlastimil Babka , Alexey Avramov , Rik van Riel , Mike Galbraith , Darrick Wong , regressions@lists.linux.dev, Linux-fsdevel , Linux-MM , LKML Subject: Re: [PATCH v4 1/1] mm: vmscan: Reduce throttling due to a failure to make progress Message-ID: <20211206112545.GF3366@techsingularity.net> References: <20211202150614.22440-1-mgorman@techsingularity.net> <20211202165220.GZ3366@techsingularity.net> <20211203090137.GA3366@techsingularity.net> <20211203190807.GE3366@techsingularity.net> Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) On Sun, Dec 05, 2021 at 10:06:27PM -0800, Shakeel Butt wrote: > On Fri, Dec 3, 2021 at 11:08 AM Mel Gorman wrote: > > > [...] > > > I am in agreement with the motivation of the whole series. I am just > > > making sure that the motivation of VMSCAN_THROTTLE_NOPROGRESS based > > > throttle is more than just the congestion_wait of > > > mem_cgroup_force_empty_write. > > > > > > > The commit that primarily targets congestion_wait is 8cd7c588decf > > ("mm/vmscan: throttle reclaim until some writeback completes if > > congested"). The series recognises that there are other reasons why > > reclaim can fail to make progress that is not directly writeback related. > > > > I agree with throttling for VMSCAN_THROTTLE_[WRITEBACK|ISOLATED] > reasons. Please explain why we should throttle for > VMSCAN_THROTTLE_NOPROGRESS? Also 69392a403f49 claims "Direct reclaim > primarily is throttled in the page allocator if it is failing to make > progress.", can you please explain how? It could happen if the pages on the LRU are being reactivated continually or holding an elevated reference count for some reason (e.g. gup, page migration etc). The event is probably transient, hence the short throttling. -- Mel Gorman SUSE Labs