public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
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


  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 [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 [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