From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) (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 DD03817736 for ; Wed, 15 Apr 2026 03:30:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.98 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776223846; cv=none; b=XKnRo1YHLFfoXecxhQTURWAjCc4FxLUGFmw6x4iisVkzpxKPT3jRVIXPGdX1rbmq1fEZjNZd0MejqVqpmZ+CV9W8ncljp5r324LcOJhlaR6eKzjjV/nNoOlMU4Ibe0pnP2JmrKGGmsd9alEuqCp5S7fFlwQ/1spbgpEcvswGdHs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776223846; c=relaxed/simple; bh=kCmZ8zVl+PSEYND1vrOTejg+s9q8FxO/akdsPU6tAw0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=S5i6MOyis5b1JqA73FT2BLnOC8UtYZpYAMbVXsJkUZhajpz9F6If8+3yGyKRKfMnZgonIqUhSQA1IfNUxGZBujahtOw6hkwvMzCCw+eLxVjcRfwQFSco0SmVZjBKMkSOg9KpqMyAtnvQRgwmRmuclZfQ9592Vbs6ZYqD0aPRcHY= 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=rG7uGvLI; arc=none smtp.client-ip=115.124.30.98 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="rG7uGvLI" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776223841; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=xxiISHwatfYyBpYrcI5ZkUw+BZUuOyeCx68MCny46Mo=; b=rG7uGvLI982Wo+yT6oKCRdRP0/2BXg1pA7YyP/OS/0kMpIigCaBs4oazWLnty04N5/XyCDZuMlVU+eaXao4si8pcuoqBPA0/NlZRDY9QCGzCX/ABt0ddyvm8Mk+JwqCwr78w3UOVaIZ+pTE77zHle1kZIYl6tYRCkJqP5xEKo8E= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R561e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037033178;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=25;SR=0;TI=SMTPD_---0X136NgQ_1776223838; Received: from 30.74.144.121(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X136NgQ_1776223838 cluster:ay36) by smtp.aliyun-inc.com; Wed, 15 Apr 2026 11:30:39 +0800 Message-ID: <1ab805f5-42c0-451d-9a81-0c96c1e2808c@linux.alibaba.com> Date: Wed, 15 Apr 2026 11:30:38 +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 v5 09/14] mm/mglru: use the common routine for dirty/writeback reactivation 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, Qi Zheng References: <20260413-mglru-reclaim-v5-0-8eaeacbddc44@tencent.com> <20260413-mglru-reclaim-v5-9-8eaeacbddc44@tencent.com> From: Baolin Wang In-Reply-To: <20260413-mglru-reclaim-v5-9-8eaeacbddc44@tencent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/13/26 12:48 AM, Kairui Song via B4 Relay wrote: > From: Kairui Song > > Currently MGLRU will move the dirty writeback folios to the second > oldest gen instead of reactivate them like the classical LRU. This > might help to reduce the LRU contention as it skipped the isolation. > But as a result we will see these folios at the LRU tail more frequently > leading to inefficient reclaim. > > Besides, the dirty / writeback check after isolation in > shrink_folio_list is more accurate and covers more cases. So instead, > just drop the special handling for dirty writeback, use the common > routine and re-activate it like the classical LRU. > > This should in theory improve the scan efficiency. These folios will be > rotated back to LRU tail once writeback is done so there is no risk of > hotness inversion. And now each reclaim loop will have a higher > success rate. This also prepares for unifying the writeback and > throttling mechanism with classical LRU, we keep these folios far from > tail so detecting the tail batch will have a similar pattern with > classical LRU. > > The micro optimization that avoids LRU contention by skipping the > isolation is gone, which should be fine. Compared to IO and writeback > cost, the isolation overhead is trivial. > > And using the common routine also keeps the folio's referenced bits > (tier bits), which could improve metrics in the long term. Also no > more need to clean reclaim bit as the common routine will make use > of it. > > Note the common routine updates a few throttling and writeback counters, > which are not used, and never have been for the MGLRU case. We will > start making use of these in later commits. > > Reviewed-by: Axel Rasmussen > Signed-off-by: Kairui Song > --- From my testing, I haven't encountered the case I was concerned about before[1]. So far, so good. Reviewed-by: Baolin Wang [1] https://lore.kernel.org/all/703627b8-4c7b-483a-8c5d-379d98400154@linux.alibaba.com/