From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) (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 476A0330D3B for ; Thu, 26 Mar 2026 08:01:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774512106; cv=none; b=jKbaNUuZIhyiDhmwyC9I6lbeEu2UdgBA7avQ7yViJBxT8EnSdSo2AyDYMhXtj6wWM3vtIke9YPgTM8ji87dIqdpvNRjIWmh067A2AVkTwtUCFqIJFvxv/sSLa2g2AjPD6y8Z2ZsGqDqVVkVtVvxhVVoS1dhD151c/ZPZb9RBBAA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774512106; c=relaxed/simple; bh=fKcYHVTYUWh/8qT2Blmvxi/T3s/fDDpoHgFxq6jKPYE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IZDgK4BHVDwXJfO2R/0gjEvbaGIRUQeeFNQbV1ZR20gYFAeQklRpCTOsh8VD7HvL5p88357PaedbHJfKUG8UZRXpE2v0zxZDYtHokT70+dfyqhfjwWPpRxakOTQB9InGvqyEFM5TeQsyeFvAUTMQg66a1iS5KGjjZe4zqvrC8Ak= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=pBsB5Pjw; arc=none smtp.client-ip=115.124.30.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="pBsB5Pjw" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1774512100; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=+W5gqz+rPqP69gORr+nBXsRDDIcM/5iD8CnLmX0DLIU=; b=pBsB5PjwyEdxQl/iaX4eFxnKZ1hC7U4PH9K+RRtoeCn0ikCLkCI6H58RM+d8sWXp7cjurHXBQPPZTeKtf6VvAA4+5P49Q8GsfXxzE/w764wgVlJzx9+AEt5Nh3JZiSZSgpBEwk7MZ5xyRAIFdr7Sj35lO52K0uripGTVUtoK8qU= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R991e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=24;SR=0;TI=SMTPD_---0X.kcYdn_1774511780; Received: from 30.74.144.123(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X.kcYdn_1774511780 cluster:ay36) by smtp.aliyun-inc.com; Thu, 26 Mar 2026 15:56:21 +0800 Message-ID: <6bce7af6-3c34-42d2-afa9-5ba8d63068be@linux.alibaba.com> Date: Thu, 26 Mar 2026 15:56:20 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 7/8] mm/mglru: simplify and improve dirty writeback handling To: kasong@tencent.com, linux-mm@kvack.org Cc: Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , David Stevens , Chen Ridong , Leno Hou , Yafang Shao , Yu Zhao , Zicheng Wang , Kalesh Singh , Suren Baghdasaryan , Chris Li , Vernon Yang , linux-kernel@vger.kernel.org References: <20260318-mglru-reclaim-v1-0-2c46f9eb0508@tencent.com> <20260318-mglru-reclaim-v1-7-2c46f9eb0508@tencent.com> From: Baolin Wang In-Reply-To: <20260318-mglru-reclaim-v1-7-2c46f9eb0508@tencent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/18/26 3:09 AM, Kairui Song via B4 Relay wrote: > From: Kairui Song > > The current handling of dirty writeback folios is not working well for > file page heavy workloads: Dirty folios are protected and move to next > gen upon isolation of getting throttled or reactivated upon pageout > (shrink_folio_list). > > This might help to reduce the LRU lock contention slightly, but as a > result, the ping-pong effect of folios between head and tail of last two > gens is serious as the shrinker will run into protected dirty writeback > folios more frequently compared to activation. The dirty flush wakeup > condition is also much more passive compared to active/inactive LRU. > Active / inactve LRU wakes the flusher if one batch of folios passed to > shrink_folio_list is unevictable due to under writeback, but MGLRU > instead has to check this after the whole reclaim loop is done, and then > count the isolation protection number compared to the total reclaim > number. > > And we previously saw OOM problems with it, too, which were fixed but > still not perfect [1]. > > So instead, just drop the special handling for dirty writeback, just > re-activate it like active / inactive LRU. And also move the dirty flush > wake up check right after shrink_folio_list. This should improve both > throttling and performance. Make sense to me. Additionally, I think there is still room to improve the writeback-related logic in shrink_folio_list().