From: Ridong Chen <ridong.chen@linux.dev>
To: Barry Song <baohua@kernel.org>, Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
David Hildenbrand <david@kernel.org>,
Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Lorenzo Stoakes <ljs@kernel.org>,
Kairui Song <kasong@tencent.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Zhongkun He <hezhongkun.hzk@bytedance.com>,
Muchun Song <muchun.song@linux.dev>,
Davidlohr Bueso <dave@stgolabs.net>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Ridong Chen <chenridong@xiaomi.com>
Subject: Re: [PATCH -v4 1/4] mm/vmscan: fix anon-only reclaim evicting file pages when swappiness=max
Date: Tue, 28 Jul 2026 09:02:58 +0800 [thread overview]
Message-ID: <2fd4c2f8-3166-4432-9192-17bdb2627138@linux.dev> (raw)
In-Reply-To: <CAGsJ_4znMXrSYEjWOP0jA11=paJWmWu9fOPAfZD6iP11viys0g@mail.gmail.com>
On 7/27/2026 6:56 PM, Barry Song wrote:
> On Mon, Jul 27, 2026 at 4:19 PM Michal Hocko <mhocko@suse.com> wrote:
>>
>> On Fri 24-07-26 11:34:32, Ridong wrote:
>>> From: Ridong Chen <chenridong@xiaomi.com>
>>>
>>> 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.
>>
>> But if can_reclaim_anon_pages tells us that anonymous pages are not
>> reclaimable then it makes no sense to try that, no? What do you expect
>> to see? An OOM killer?
>
> This is proactive reclaim rather than direct reclaim, and
> SWAPPINESS_ANON_ONLY is only supported for proactive reclaim. It
> therefore cannot invoke the OOM killer.
>
> If I understand correctly, this is exactly the issue this patch is
> trying to address. Instead of falling back to reclaiming file folios,
> it returns "bash: echo: write error: Resource temporarily unavailable".
>
> 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
>
> Ridong, please correct me if I am wrong.
Thank you, Barry, it's correct.
--
Best regards
Ridong
next prev parent reply other threads:[~2026-07-28 1:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 3:34 [PATCH -v4 0/4] mm/vmscan: fix swappiness=max and clean up per-node proactive reclaim Ridong
2026-07-24 3:34 ` [PATCH -v4 1/4] mm/vmscan: fix anon-only reclaim evicting file pages when swappiness=max Ridong
2026-07-27 8:19 ` Michal Hocko
2026-07-27 10:56 ` Barry Song
2026-07-27 11:07 ` Michal Hocko
2026-07-28 1:02 ` Ridong Chen [this message]
2026-07-27 11:37 ` Michal Hocko
2026-07-27 22:35 ` Barry Song
2026-07-28 7:18 ` Michal Hocko
2026-07-28 10:03 ` Barry Song
2026-07-28 11:53 ` Michal Hocko
2026-07-28 12:18 ` Barry Song
2026-07-24 3:34 ` [PATCH -v4 2/4] mm: vmscan: propagate real error code from per-node proactive reclaim Ridong
2026-07-24 3:34 ` [PATCH -v4 3/4] mm: vmscan: drop unused gfp_mask parameter from __node_reclaim() Ridong
2026-07-24 3:34 ` [PATCH -v4 4/4] mm/mglru: fix anon-only reclaim evicting file pages when swappiness=max Ridong
2026-07-24 7:18 ` Kairui Song
2026-07-24 8:29 ` Barry Song
2026-07-27 6:37 ` Baolin Wang
2026-07-24 5:37 ` [PATCH -v4 0/4] mm/vmscan: fix swappiness=max and clean up per-node proactive reclaim Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2fd4c2f8-3166-4432-9192-17bdb2627138@linux.dev \
--to=ridong.chen@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=chenridong@xiaomi.com \
--cc=dave@stgolabs.net \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hezhongkun.hzk@bytedance.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=qi.zheng@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.