From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (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 353AA14B950 for ; Mon, 20 Jul 2026 04:42:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784522574; cv=none; b=WD9HorPBFtmAJ96QgawpD2CPQqzOOGZWp3yGyiorGrwhvJFaiMH+MvyZLaCdYNy46Aj79vFlmc1rsRiW56Ot/4Me4PKvfvMIT4/E/KWxEfw09NoBWa7lUDwOhTUSb4RkLmT39Ad0G5uVQzVPBv49kaHwTDz31upHyksJ6+nOO24= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784522574; c=relaxed/simple; bh=X44zuTNMhG682QJfY5wCr/leNmBVmPAYW3zlM/zS20U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=O0J5Wqt3oEKQ3pvrAHSjtDxAmIqvpxZJmmKw55Up5rldZnzdRq4fMzlb5hWs5JH2iT4+Bt9exAY9hJrn0szFSAyRl48mfQunKvoRZ/mOoeYjj4m+jLUoCmTEQ+06+CjWGjR8dKYW4Xi3ejwkOX6rYJNp9p/PwzXVDD86WNaBEMc= 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=JY+o/BAB; arc=none smtp.client-ip=91.218.175.174 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="JY+o/BAB" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784522568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XAnwXaAATsOLEHJoanRaTBrNyT5v1P4RBlA4x0esH0s=; b=JY+o/BAB/uuKPTec0ANjPlAKtGb1z4II6LDbrFoOGHJIiJDulI1oetOHjRRAB4lNzCFZgo /rDgLfRH05eM464IXuPzcyv7XSssziWTt4akPGhSqp2z05CEgXgANJousagSF1Eg+KYN8I Djdy6CwQvXMax3ducEvX55eKYqbBZv8= Date: Mon, 20 Jul 2026 12:42:32 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2 1/4] mm/vmscan: fix anon-only reclaim evicting file pages when swappiness=max To: Barry Song Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, david@kernel.org, mhocko@kernel.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, ljs@kernel.org, kasong@tencent.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, hezhongkun.hzk@bytedance.com, muchun.song@linux.dev, dave@stgolabs.net, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ridong Chen References: <20260718095251.82937-1-ridong.chen@linux.dev> <20260718095251.82937-2-ridong.chen@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ridong Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 7/18/2026 9:34 PM, Barry Song wrote: > On Sat, Jul 18, 2026 at 5:54 PM Ridong Chen wrote: >> >> From: Ridong Chen >> >> As Qi mentioned [1], when swappiness=max (SWAPPINESS_ANON_ONLY) is set, >> the reclaim logic is expected to reclaim anonymous pages exclusively. >> However, due to the current ordering of checks in get_scan_count(), >> file pages may still be evicted if can_reclaim_anon_pages() returns >> false, which contradicts the semantics of SWAPPINESS_ANON_ONLY. >> >> Reproducer in a cgroup holding 64M of file cache, with no swap configured: >> >> Before (file cache is wrongly evicted): >> # cat memory.stat >> anon 196608 >> file 67178496 >> pgscan_proactive 0 >> # echo "64M swappiness=max" > memory.reclaim >> # cat memory.stat >> anon 208896 >> file 4096 <- page cache evicted >> pgsteal_proactive 16400 >> pgscan_proactive 16400 >> >> After (file cache is left intact): >> # cat memory.stat >> anon 200704 >> file 67178496 >> pgscan_proactive 0 >> # echo "64M swappiness=max" > memory.reclaim >> -bash: echo: write error: Resource temporarily unavailable >> # cat memory.stat >> anon 208896 >> file 67178496 <- page cache untouched >> pgsteal_proactive 0 >> pgscan_proactive 0 >> >> Fix this by bailing out early when SWAPPINESS_ANON_ONLY is set and no >> anonymous pages are reclaimable, before falling back to file reclaim. >> >> [1] https://lore.kernel.org/cgroups/7ddf3eee-5fe2-45f7-8614-c8936a039e04@linux.dev/ >> >> Fixes: 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim") >> Suggested-by: Qi Zheng >> Acked-by: Shakeel Butt >> Acked-by: Johannes Weiner >> Reviewed-by: Muchun Song >> Signed-off-by: Ridong Chen > > Reviewed-by: Barry Song > >> --- >> mm/vmscan.c | 18 +++++++++++------- >> 1 file changed, 11 insertions(+), 7 deletions(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index 35c3bb15ae96..d6b383d96a0c 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -2501,6 +2501,17 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, >> enum scan_balance scan_balance; >> enum lru_list lru; >> >> + /* Proactive reclaim initiated by userspace for anonymous memory only */ >> + if (swappiness == SWAPPINESS_ANON_ONLY) { >> + WARN_ON_ONCE(!sc->proactive); > > I feel it's a bit odd that the WARN_ON_ONCE() is placed here. Maybe > adding a short comment would make the intent clearer. For example: > "SWAPPINESS_ANON_ONLY is only allowed for proactive reclaim." Hi Barry, I didn't change the original logic in this patch. I agree that adding a comment would help clarify the intent. I'll include that in the next version. > I'm not sure whether it would be better to issue this warning earlier, > for example in try_to_free_mem_cgroup_pages(). That said, I don't > feel strongly about this. Since patch 4 will address the MGLRU issue and could also include this warning, I think that triggering the warning earlier makes sense and would be more general. Would it be acceptable to add a separate patch (e.g., patch 5) for moving the warning? That way, each patch stays focused on a single logical change. -- Best regards Ridong