From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (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 1E8D346B5 for ; Wed, 15 Apr 2026 03:20:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.113 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776223207; cv=none; b=sr8m/cx54LVoiJI5KOujwawRbMP/Pdaxzh+jSFqQNHL79gmYMHnn17IL0dK2IflChr2q5fYMgEbNpsVJblZDNJyRQxzZAqBHF+i/SPnnUSZAUuEMwJ2EqYlmcUwgzzCRYp26Dl6xFdLnuJmzrUdz78T4rEH/kcnzHffn89A5/yE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776223207; c=relaxed/simple; bh=nodco5o7lfI0rSjzvdrAUu//UiSY9Q8kFFZfl8y0Idw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=AKdhnQeVA0czCSKevIqOV9JoYFjMadmwAcs6Xnf4NZ4BC+XATj+oXO06dBJIInO8qqgynFaeBQmBxmUgKhUg+U5lwkqGo3LqVOXSI7XKR23xU4qN/HEXkEpQHnEjWQG07SAIsZrCdqE1vuIVFDLryQJ33Gd9G315kz2HM2CxmMo= 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=mCl08fRN; arc=none smtp.client-ip=115.124.30.113 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="mCl08fRN" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776223198; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=CcGhwNl9tCxinhH/Mw8L5+KsTgwgIEcOsH66vEObKtk=; b=mCl08fRNOarRmS340998tG3Ba5P+uB74ch/UPzcFSEnOBJTlx3CbbrZ5YKCSe3guLFKzb6wUjOedq+3EFFPVR4aDlij30PoMKJ5xHySKO2nQKk/BqiTl57i1/Hlxu1sI6IDbFumq/IM5nssRRH/goNOqvljBve1UCLlDn7gAw9g= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R121e4;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=25;SR=0;TI=SMTPD_---0X136K2n_1776223196; Received: from 30.74.144.121(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X136K2n_1776223196 cluster:ay36) by smtp.aliyun-inc.com; Wed, 15 Apr 2026 11:19:56 +0800 Message-ID: Date: Wed, 15 Apr 2026 11:19:55 +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 08/14] mm/mglru: remove redundant swap constrained check upon isolation 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-8-8eaeacbddc44@tencent.com> From: Baolin Wang In-Reply-To: <20260413-mglru-reclaim-v5-8-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 > > Remove the swap-constrained early reject check upon isolation. This > check is a micro optimization when swap IO is not allowed, so folios are > rejected early. But it is redundant and overly broad since > shrink_folio_list() already handles all these cases with proper > granularity. > > Notably, this check wrongly rejected lazyfree folios, and it doesn't > cover all rejection cases. shrink_folio_list() uses may_enter_fs(), > which distinguishes non-SWP_FS_OPS devices from filesystem-backed swap > and does all the checks after folio is locked, so flags like swap cache > are stable. > > This check also covers dirty file folios, which are not a problem now > since sort_folio() already bumps dirty file folios to the next > generation, but causes trouble for unifying dirty folio writeback > handling. > > And there should be no performance impact from removing it. We may have > lost a micro optimization, but unblocked lazyfree reclaim for NOIO > contexts, which is not a common case in the first place. > > Reviewed-by: Axel Rasmussen > Signed-off-by: Kairui Song > --- LGTM. Reviewed-by: Baolin Wang