linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Gregory Price <gourry@gourry.net>, linux-mm@kvack.org
Cc: linux-kernel@kvack.org, osalvador@suse.de,
	gregkh@linuxfoundation.org, rafael@kernel.org,
	akpm@linux-foundation.org
Subject: Re: [PATCH] mm: add build-time option to set hotplug default type
Date: Fri, 20 Dec 2024 15:59:58 +0100	[thread overview]
Message-ID: <11911ad7-527b-411b-9896-fea06bf38a26@redhat.com> (raw)
In-Reply-To: <20241220144518.206208-1-gourry@gourry.net>

On 20.12.24 15:45, Gregory Price wrote:
> When memory hotplug auto-online is enabled, hotplug memory blocks are
> onlined into ZONE_NORMAL by default. The `memhp_default_state` boot
> param allows runtime configuration, but no build-time config exists.

+ you can configure it at runtime.

> 
> Add a build-time configuration option to change default hotplug zone.
> 
> build config:
>    MEMHP_DEFAULT_TYPE
> 
> Selections:
>    MEMHP_DEFAULT_TYPE_NORMAL  => mhp_default_online_type = "online"
>    MEMHP_DEFAULT_TYPE_MOVABLE => mhp_default_online_type = "online_movable"
> 
> When MEMORY_HOTPLUG_DEFAULT_ONLINE is disabled, MEMHP_DEFAULT_TYPE is
> set to "offline" to match the current system behavior.
> 
> ZONE_NORMAL still remains the default, because for systems with a large
> amount of hotplug memory, defaulting it to ZONE_MOVABLE may result in
> portions failing to online if sufficient ZONE_NORMAL memory does not
> exist to describe it.
> 

What's the use case?

I'm hoping that we can move away from the compile-time option and let 
user space, who better knows what to do (especially with different kinds 
of memory having different requirements) configure auto-onlining or 
online manually (e.g., devdax).

For example, in RHEL we traditionally use udev rules, because we want a 
different behavior on bare-metal vs. VMs, but they are not particularly 
easy to extend to implement wilder policies.

For a while I worked on a systemd unit [1] to configure+handle memory 
onlining so we can get rid of the udev rules we use in RHEL. But it only 
configured+handled having "one type of hotplugged memort".

I'm planning on picking that up again at some point, to also make it 
possible to handle different policies for different memory types.

For example, maybe someone wants to auto-online virtio-mem memory to 
ZONE_NORMAL, but let onlining of devdax memory be handled by the devdax 
utility (e.g. ZONE_MOVABLE). We can identify in some cases "what" memory 
was added using /proc/iomem.

[1] https://github.com/davidhildenbrand/systemd/tree/memoryhotplugd

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2024-12-20 15:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-20 14:45 Gregory Price
2024-12-20 14:59 ` David Hildenbrand [this message]
2024-12-20 15:17   ` Gregory Price
2024-12-20 15:56     ` David Hildenbrand
2024-12-20 16:04 ` David Hildenbrand
2024-12-20 16:37   ` Gregory Price
2024-12-20 18:25     ` David Hildenbrand
2024-12-20 18:36       ` Gregory Price
2024-12-20 18:25   ` Gregory Price
2024-12-20 18:26     ` David Hildenbrand

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=11911ad7-527b-411b-9896-fea06bf38a26@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=gourry@gourry.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@kvack.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    --cc=rafael@kernel.org \
    /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