All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	akpm@linux-foundation.org, hca@linux.ibm.com,
	linux-s390@vger.kernel.org, brauner@kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	timmurray@google.com, "Liam R. Howlett" <Liam.Howlett@oracle.com>
Subject: Re: [PATCH v1 2/3] mm: process_mrelease: skip LRU movement for exclusive file folios
Date: Wed, 29 Apr 2026 16:44:16 +0200	[thread overview]
Message-ID: <afIZQOtaBabeHtCc@tiehlicka> (raw)
In-Reply-To: <4a612d63-2838-40f5-ab67-79bf35dd3a56@kernel.org>

On Wed 29-04-26 15:07:04, David Hildenbrand wrote:
> On 4/29/26 12:33, Michal Hocko wrote:
> > On Wed 29-04-26 11:09:55, David Hildenbrand wrote:
> >> Unrelated stupid question: would things be clearer if we could rename
> >> MMF_UNSTABLE to MMF_OOM_REAPING once figure out whether aborting fork() still
> >> really needs it?
> > 
> > While the oom is the only current kernel user of MMF_UNSTABLE (in a
> > sense it sets the flag) the flag should denote that any page faults are
> > reliable because it might fault in a fresh memory and user would lose
> > the previous content without knowing that. Not sure MMF_OOM_REAPING
> > would reflect that reality better.
> 
> We use it for failed fork() as well, but that's slightly different semantics (no
> real page faults ever made sense).

The bottom line is the same. Make sure PF fails rather than silently
provide potentially corrupted data.

> Looking at the original patch here, using MMF_OOM_REAPING to modify zapping
> behavior would be clearer than MMF_UNSTABLE, I guess.

Ohh, you mean to add a new flag, right?
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2026-04-29 14:44 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-21 23:02 [PATCH v1 0/3] mm: process_mrelease: expedite clean file folio reclaim and add auto-kill Minchan Kim
2026-04-21 23:02 ` [PATCH v1 1/3] mm: process_mrelease: expedite clean file folio reclaim via mmu_gather Minchan Kim
2026-04-24  7:56   ` David Hildenbrand (Arm)
2026-04-24 21:24     ` Minchan Kim
2026-04-27  9:29       ` David Hildenbrand (Arm)
2026-04-27 22:04         ` Minchan Kim
2026-04-24 19:33   ` Matthew Wilcox
2026-04-24 21:56     ` Minchan Kim
2026-05-05 14:53   ` Alexander Gordeev
2026-05-08 21:56     ` Minchan Kim
2026-05-11 16:13       ` Alexander Gordeev
2026-05-11 21:48         ` Minchan Kim
2026-04-21 23:02 ` [PATCH v1 2/3] mm: process_mrelease: skip LRU movement for exclusive file folios Minchan Kim
2026-04-22  7:22   ` Baolin Wang
2026-04-23 23:38     ` Minchan Kim
2026-04-24  7:51   ` Michal Hocko
2026-04-24  7:57     ` David Hildenbrand (Arm)
2026-04-24 19:15       ` Minchan Kim
2026-04-27  7:16         ` Michal Hocko
2026-04-27 16:48           ` Suren Baghdasaryan
2026-04-27 17:15             ` Michal Hocko
2026-04-27 23:05               ` Minchan Kim
2026-04-28  6:56                 ` Michal Hocko
2026-04-29  1:19                   ` Minchan Kim
2026-04-29  8:18                     ` Michal Hocko
2026-04-29  9:09                       ` David Hildenbrand (Arm)
2026-04-29 10:33                         ` Michal Hocko
2026-04-29 13:07                           ` David Hildenbrand (Arm)
2026-04-29 14:44                             ` Michal Hocko [this message]
2026-04-30  6:08                               ` David Hildenbrand (Arm)
2026-05-08 20:57                                 ` Liam R. Howlett
2026-05-11 13:05                                   ` David Hildenbrand (Arm)
2026-05-13  6:47                                   ` Michal Hocko
2026-04-29 21:41                         ` Minchan Kim
2026-04-30 14:38                           ` David Hildenbrand (Arm)
2026-04-29  8:55                     ` David Hildenbrand (Arm)
2026-04-29 21:42                       ` Minchan Kim
2026-04-24 19:26     ` Minchan Kim
2026-04-21 23:02 ` [PATCH v1 3/3] mm: process_mrelease: introduce PROCESS_MRELEASE_REAP_KILL flag Minchan Kim
2026-04-24  7:57   ` Michal Hocko
2026-04-24 22:49     ` Minchan Kim
2026-04-27  7:02       ` Michal Hocko
2026-04-27 22:03         ` Minchan Kim
2026-04-28  7:01           ` Michal Hocko
2026-04-28 22:37             ` Minchan Kim
2026-04-29  8:25               ` Michal Hocko
2026-04-29 20:01                 ` Suren Baghdasaryan
2026-04-29 21:17                   ` Minchan Kim
2026-04-29 21:16                 ` Minchan Kim
2026-04-27 20:34   ` Suren Baghdasaryan
2026-04-27 22:52     ` Minchan Kim

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=afIZQOtaBabeHtCc@tiehlicka \
    --to=mhocko@suse.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=david@kernel.org \
    --cc=hca@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.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 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.