From: David Hildenbrand <david@redhat.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>, Michal Hocko <mhocko@suse.com>,
Oscar Salvador <osalvador@suse.de>,
linux-doc@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v1 3/3] memory-hotplug.rst: document the "auto-movable" online policy
Date: Fri, 8 Oct 2021 10:33:13 +0200 [thread overview]
Message-ID: <09027675-5737-a076-7616-277aeb38427c@redhat.com> (raw)
In-Reply-To: <YV6jpoVERotn/New@kernel.org>
>> It's essentially ignored with the auto-movable policy for memory hotplugged
>> after boot (!MEMBLOCK_HOTPLUG). That's why only the description of
>> "contig-zones" below describes how it interacts with the ``movable_node``,
>> and we make it clear here that it's restricted to the "contig-zones" policy
>> as well.
>>
>> <details>
>> Bare metal, where we care about reliably unplugging hotplugged memory
>> usually configures auto-onlining to "online_movable": for example, that's
>> the case on RHEL. auto-movable doesn't make too much sense for bare metal:
>> the nature of "movable_node" is to essentially online anything that might
>> get hotunplugged MOVABLE, especially after hotplugging memory and rebooting:
>> that is highly dangerous especially in virtualized environments.
>>
>> "auto-movable" is valuable in virtualized environments, where we add memory
>> via:
>> * add_memory_driver_managed() like virtio-mem, whereby such memory is
>> never part of the firmware provided memory-map, so the policy is
>> always in control even after a reboot.
>> * Hotplugged virtual DIMMs, such as provided by x86-64/arm64, whereby we
>> don't include these DIMMs in the firmware-provided memory map, but
>> ACPI code adds them after early boot, making it behave similar to
>> add_memory_driver_managed() -- the policy is always in control even
>> after a reboot.
>> </details>
>
> Do you want to put it somewhere in Documentation/ ?
> It's already written anyway ;-)
>
I'll add to the "auto-movable" description:
"This policy ignores the ``movable_node`` kernel command line parameter
and isn't really applicable in environments that require it (e.g., bare
metal with hotunpluggable nodes) where hotplugged memory might be
exposed via the firmware-provided memory map early during boot to the
system instead of getting detected, added and onlined later during boot
(such as done by virito-mem or by some hypervisors implementing emulated
DIMMs)."
Thanks Mike!
--
Thanks,
David / dhildenb
prev parent reply other threads:[~2021-10-08 8:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-30 14:41 [PATCH v1 0/3] " David Hildenbrand
2021-09-30 14:41 ` [PATCH v1 1/3] memory-hotplug.rst: fix two instances of "movablecore" that should be "movable_node" David Hildenbrand
2021-09-30 14:41 ` [PATCH v1 2/3] memory-hotplug.rst: fix wrong /sys/module/memory_hotplug/parameters/ path David Hildenbrand
2021-09-30 14:41 ` [PATCH v1 3/3] memory-hotplug.rst: document the "auto-movable" online policy David Hildenbrand
2021-10-06 0:35 ` Mike Rapoport
2021-10-06 8:01 ` David Hildenbrand
2021-10-07 7:37 ` Mike Rapoport
2021-10-08 8:33 ` David Hildenbrand [this message]
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=09027675-5737-a076-7616-277aeb38427c@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=rppt@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