From: Michal Hocko <mhocko@suse.com>
To: Minchan Kim <minchan@kernel.org>
Cc: akpm@linux-foundation.org, david@kernel.org, brauner@kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
surenb@google.com, timmurray@google.com
Subject: Re: [RFC 0/3] mm: process_mrelease: expedited reclaim and auto-kill support
Date: Thu, 23 Apr 2026 09:50:47 +0200 [thread overview]
Message-ID: <aenPV9ewKAzRF2Vg@tiehlicka> (raw)
In-Reply-To: <aeagUxlju40rvkYQ@google.com>
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. I am NOT NAKing this patch though but please make sure you have a
wider support for this idea before this gets merged. Also make sure that
all the above reasoning is part of the changelog if you want to get this
merged.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2026-04-23 7:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 22:39 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 [this message]
2026-04-23 9:49 ` David Hildenbrand (Arm)
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=aenPV9ewKAzRF2Vg@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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