From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (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 7A81926F2B9 for ; Mon, 27 Jul 2026 06:37:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.118 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785134258; cv=none; b=RncvADgept6upW2zSOy0K607QvuNgs3tQ//141x/sC9Lvc8+iRfY3DTfpgBvKBxqG8WgSW1yk7gc1PkHKy94NM2L+OhrvHii4XK2ei7Tx6Kn6ZPuc+ZgHPqGabW/yfG85DRT/gn/4tYk5QuY0BRAL/vwUagTnc6/5szLGCYP5tc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785134258; c=relaxed/simple; bh=E42JZ0lCJFokb2JlOCwgjBl5CRxXiYOiJL3J4lH8VOA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=a+D1AdFB6Q7kg1/vXcI5y1CMiqDBsEbYs9ZPXe5UwefCz1r5UWPxRbII0bEMdeOBq1N3PBfvPSgHX0oROwscODHI6IRqKadFhD04XkZmesF1y8m65gyV5Tqx0gxNVBv7UPlBW8EPnqMMuqC4uSeA5pl3iUMmYyxgBffgCI1y72Q= 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=pdcW4VwJ; arc=none smtp.client-ip=115.124.30.118 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="pdcW4VwJ" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1785134251; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=o24wMPf0kRDK1xDY68nvHO3rd5V4v/8M7uZkH4mb2os=; b=pdcW4VwJwmv+RxczW+JNGl/XfQM47goeRf1gWgspsqUs/GjdShThL68U+pSWT1sNC5Nd85gN9q0mpvlyOqy+aTTx0Mf1LgnuJrWEXH/Ld4ERVFTc69Hu9oQbYqOnOVE6a2M+5FopiegMxLlV1KeJVXojo/hTPwFqig/Nyt/OuD4= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=20;SR=0;TI=SMTPD_---0X7qdXMt_1785134248; Received: from 30.74.144.127(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X7qdXMt_1785134248 cluster:ay36) by smtp.aliyun-inc.com; Mon, 27 Jul 2026 14:37:29 +0800 Message-ID: Date: Mon, 27 Jul 2026 14:37:28 +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 -v4 4/4] mm/mglru: fix anon-only reclaim evicting file pages when swappiness=max To: Ridong , Andrew Morton , Johannes Weiner Cc: David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Zhongkun He , Muchun Song , Davidlohr Bueso , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ridong Chen References: <20260724033435.2573323-1-ridong.chen@linux.dev> <20260724033435.2573323-5-ridong.chen@linux.dev> From: Baolin Wang In-Reply-To: <20260724033435.2573323-5-ridong.chen@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/24/26 11:34 AM, Ridong wrote: > From: Ridong Chen > > The previous patch fixed this issue for the traditional LRU. The same > problem exists in MGLRU [1]: when swappiness=max (SWAPPINESS_ANON_ONLY) > is set, reclaim is expected to evict anonymous pages exclusively, but > file pages can still be reclaimed when anonymous pages cannot be > reclaimed (e.g. no swap and no demotion target). > > Fix it the same way as the traditional LRU: keep returning > SWAPPINESS_ANON_ONLY in get_swappiness(), and return 0 from > get_nr_to_scan() when SWAPPINESS_ANON_ONLY is set but anon pages cannot > be reclaimed. Since get_nr_to_scan() decides how much MGLRU scans, > returning 0 skips the scan entirely and avoids the useless scan work > when there is nothing eligible to reclaim. > > The test result: > Before fix: > > # cat /sys/kernel/mm/lru_gen/enabled > 0x0007 > # cat memory.stat > anon 204800 > file 67108864 > ... > pgsteal_proactive 0 > pgscan_proactive 0 > > # echo "64M swappiness=max" > memory.reclaim > # cat memory.stat > anon 208896 > file 0 > ... > pgsteal_proactive 16384 > pgscan_proactive 16384 > > After fix: > > # cat memory.stat > anon 188416 > file 67215360 > kernel 1970176 > ... > pgsteal_proactive 0 > pgscan_proactive 0 > > # echo "64M swappiness=max" > memory.reclaim > -bash: echo: write error: Resource temporarily unavailable > # cat memory.stat > anon 204800 > file 67215360 > ... > pgsteal_proactive 0 > pgscan_proactive 0 > > [1] https://sashiko.dev/#/patchset/20260717113300.214717-1-ridong.chen@linux.dev > > Fixes: 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim") > Signed-off-by: Ridong Chen > --- LGTM. Reviewed-by: Baolin Wang