All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Price <gourry@gourry.net>
To: Michal Hocko <mhocko@suse.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kernel-team@meta.com, david@redhat.com, osalvador@suse.de,
	gregkh@linuxfoundation.org, rafael@kernel.org, dakr@kernel.org,
	akpm@linux-foundation.org, lorenzo.stoakes@oracle.com,
	Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org,
	surenb@google.com, hare@suse.de
Subject: Re: [RFC PATCH] memory,memory_hotplug: allow restricting memory blocks to zone movable
Date: Tue, 6 Jan 2026 11:53:30 -0500	[thread overview]
Message-ID: <aV0-ChclC7SCrxcg@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <aV0kzBxg57Mlw8mx@tiehlicka>

On Tue, Jan 06, 2026 at 04:05:48PM +0100, Michal Hocko wrote:
> On Mon 05-01-26 15:36:11, Gregory Price wrote:
> > It was reported (LPC 2025) that userland services which monitor memory
> > blocks can cause hot-unplug to fail permanently.
> >
> > This can occur when drivers attempt to hot-remove memory in two phases
> > (offline, remove), while a userland service detects the memory offline
> > and re-onlines the memory into a zone which may prevent removal.
> 
> Are there more details about this?

The details are with Hannes, I was just recapping what was described in
his devmem talk at LPC ("To online or not online").

> 
> > This patch allows a driver to specify that a given memory block is
> > intended as ZONE_MOVABLE memory only (i.e. the system should try to
> > protect its hot-unpluggability). This is done via an MHP flag and a new
> > "movable_only" bool in `struct memory_block`.
> > 
> > Attempts to online a memory block with movable_only=true with any value
> > other than MMOP_ONLINE_MOVABLE will fail with -EINVAL.
> > 
> > It is hard to catch all possible ways to implement offline/remove
> > process, so a race condition here can clearly still occur if the
> > userland service onlines the memory back into ZONE_MOVABLE, but it at
> > least will not prevent the removal of a block at a later time.
> 
> Irrespective of the userspace note above (which seems like a policy that
> should probably be re-evaluated or allow for a better fine tuning) I can
> see some sense in drivers having a better control of which zones (kernel
> vs. movable) can their managed memory fall into.

Hannes pointed out that this is some default policy on one or more
distributions, which is quite annoying.  Obviously a kernel change to
fight against user-policy is not great, but trying to prevent
hotplug-intended memory from being onlined in hotplug-unfriendly zones
seemed like a pretty straight forward improvement.

> 
> That being said, rather than movable_only, should we have a mask of
> online types supported for the mem block?
> 

I briefly considered this.  I went with this for RFC-v1 since it's
fairly simple and because movable is really the only zone with hotplug
guarantees (any other zone makes no hotplug guarantees).

It's also significantly more complex of a change for questionable value,
but if people see this as the way to go i'll happily pivot to that.

~Gregory


  reply	other threads:[~2026-01-06 16:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-05 20:36 [RFC PATCH] memory,memory_hotplug: allow restricting memory blocks to zone movable Gregory Price
2026-01-06 15:05 ` Michal Hocko
2026-01-06 16:53   ` Gregory Price [this message]
2026-01-06 19:49     ` Michal Hocko
2026-01-07 12:47       ` Hannes Reinecke
2026-01-07 17:17         ` Michal Hocko
2026-01-07 15:09       ` David Hildenbrand (Red Hat)
2026-01-07 16:00         ` Gregory Price
2026-01-07 17:19         ` Michal Hocko
2026-01-06 15:24 ` David Hildenbrand (Red Hat)
2026-01-06 16:58   ` Gregory Price
2026-01-06 17:52     ` David Hildenbrand (Red Hat)
2026-01-06 18:06       ` Gregory Price
2026-01-06 18:38         ` David Hildenbrand (Red Hat)
2026-01-06 19:59           ` Gregory Price
2026-01-06 20:22             ` David Hildenbrand (Red Hat)
2026-01-08  7:31               ` Hannes Reinecke
2026-01-08 14:16                 ` David Hildenbrand (Red Hat)
2026-01-09 16:41                   ` Gregory Price
2026-01-12  7:28                     ` Hannes Reinecke
2026-01-12 14:23                       ` Gregory Price
2026-01-08  7:21         ` Hannes Reinecke
2026-01-08  7:22         ` Hannes Reinecke

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=aV0-ChclC7SCrxcg@gourry-fedora-PF4VCD3F \
    --to=gourry@gourry.net \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=dakr@kernel.org \
    --cc=david@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.de \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=rafael@kernel.org \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /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.