From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Michal Hocko <mhocko@suse.com>, Minchan Kim <minchan@kernel.org>
Cc: akpm@linux-foundation.org, brauner@kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
surenb@google.com, timmurray@google.com,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [RFC 0/3] mm: process_mrelease: expedited reclaim and auto-kill support
Date: Thu, 23 Apr 2026 11:49:55 +0200 [thread overview]
Message-ID: <28c3ae9f-c974-454c-b8ed-ba0ba0a5706d@kernel.org> (raw)
In-Reply-To: <aenPV9ewKAzRF2Vg@tiehlicka>
On 4/23/26 09:50, Michal Hocko wrote:
> On Mon 20-04-26 14:53:23, Minchan Kim wrote:
>> On Fri, Apr 17, 2026 at 09:11:21AM +0200, Michal Hocko wrote:
> [...]
>>> Yes. All which make sense, really. I am still not convinced about the
>>> clean page cache because that just seems like a hack to workaround wrong
>>> userspace oom heuristics.
>>
>> I see it a bit differently. When paltform decides to kill a process
>> to free up memory, they want that memory back right away.
>>
>> So it doesn't make much sense for the kernel to ignore that and leave the clean
>> file pages to be picked up slowly by kswapd later.
>>
>> In some aspects, you can think of LMKD as a more specialized, userspace version
>> of kswapd. It has high-level knowledge of process priorities and knows exactly
>> which process is safe to kill to get memory instantly. The kernel's kswapd,
>> however, operates globally without this specific process-level awareness, which
>> makes it less suited for this kind of targeted reclamation.
>>
>> If we force LMKD to rely on the slower global kswapd to actually free the clean
>> pages, it defeats the whole purpose of targeting a specific process.
>>
>> So letting process_mrelease speed this up isn't a hack at all. It's just helping
>> the kernel do what the admin wanted in the first place: fast, targeted memory.
>
> This is a very creative/disruptive way to do a memory reclaim. From a
> user POV I would much rather see clean page cache reclaimed before my
> apps start to disappear. But this is obviously your call and your users
> that will care.
>
> Anyway, I still maintain my position. I do not think it is a good
> idea to drop clean page cache as you do not know whether there are other
> users.
IIRC, Johannes raised in the past the we cannot predict the future.
For example, if an app gets OOM-killed, wouldn't we usually try restarting it,
re-consuming the clean pagecache pages we would be evicting here?
Just a thought.
--
Cheers,
David
prev parent reply other threads:[~2026-04-23 9:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 22:39 [RFC 0/3] mm: process_mrelease: expedited reclaim and auto-kill support Minchan Kim
2026-04-13 22:39 ` [RFC 1/3] mm: process_mrelease: expedite clean file folio reclaim via mmu_gather Minchan Kim
2026-04-14 7:45 ` David Hildenbrand (Arm)
2026-04-14 20:21 ` Minchan Kim
2026-04-13 22:39 ` [RFC 2/3] mm: process_mrelease: skip LRU movement for exclusive file folios Minchan Kim
2026-04-14 7:20 ` David Hildenbrand (Arm)
2026-04-14 20:22 ` Minchan Kim
2026-04-13 22:39 ` [RFC 3/3] mm: process_mrelease: introduce PROCESS_MRELEASE_REAP_KILL flag Minchan Kim
2026-04-16 9:13 ` Christian Brauner
2026-04-17 6:30 ` Minchan Kim
2026-04-17 7:04 ` Michal Hocko
2026-04-20 21:47 ` Minchan Kim
2026-04-23 7:17 ` Michal Hocko
2026-04-14 6:57 ` [RFC 0/3] mm: process_mrelease: expedited reclaim and auto-kill support Michal Hocko
2026-04-14 20:00 ` Minchan Kim
2026-04-15 7:38 ` Michal Hocko
2026-04-15 23:26 ` Minchan Kim
2026-04-16 6:54 ` Michal Hocko
2026-04-17 6:20 ` Minchan Kim
2026-04-17 7:11 ` Michal Hocko
2026-04-20 21:53 ` Minchan Kim
2026-04-23 7:50 ` Michal Hocko
2026-04-23 9:49 ` David Hildenbrand (Arm) [this message]
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=28c3ae9f-c974-454c-b8ed-ba0ba0a5706d@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=surenb@google.com \
--cc=timmurray@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox