linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: David Hildenbrand <david@redhat.com>
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: Thu, 7 Oct 2021 10:37:10 +0300	[thread overview]
Message-ID: <YV6jpoVERotn/New@kernel.org> (raw)
In-Reply-To: <4bab9000-0b49-a852-d574-1c8b2fe10de1@redhat.com>

On Wed, Oct 06, 2021 at 10:01:39AM +0200, David Hildenbrand wrote:
> On 06.10.21 02:35, Mike Rapoport wrote:
> > On Thu, Sep 30, 2021 at 04:41:17PM +0200, David Hildenbrand wrote:
> > > In commit e83a437faa62 ("mm/memory_hotplug: introduce "auto-movable" online
> > > policy") we introduced a new memory online policy to automatically
> > > select a zone for memory blocks to be onlined. We added a way to
> > > set the active online policy and tunables for the auto-movable online
> > > policy. In follow-up commits we tweaked the "auto-movable" policy to also
> > > consider memory device details when selecting zones for memory blocks to
> > > be onlined.
> > > 
> > > Let's document the new toggles and how the two online policies we have
> > > work.
> > > 
> > > Signed-off-by: David Hildenbrand <david@redhat.com>
> > > ---
> > >   .../admin-guide/mm/memory-hotplug.rst         | 128 +++++++++++++++---
> > >   1 file changed, 108 insertions(+), 20 deletions(-)
> > > 
> > > diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst
> > > index ee00b70dedde..c20a2c0031cf 100644
> > > --- a/Documentation/admin-guide/mm/memory-hotplug.rst
> > > +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
> > > @@ -165,9 +165,8 @@ Or alternatively::
> > >   	% echo 1 > /sys/devices/system/memory/memoryXXX/online
> > > -The kernel will select the target zone automatically, usually defaulting to
> > > -``ZONE_NORMAL`` unless ``movable_node`` has been specified on the kernel
> > > -command line or if the memory block would intersect the ZONE_MOVABLE already.
> > > +The kernel will select the target zone automatically, depending on the
> > > +configured ``online_policy``.
> > >   One can explicitly request to associate an offline memory block with
> > >   ZONE_MOVABLE by::
> > > @@ -198,6 +197,9 @@ Auto-onlining can be enabled by writing ``online``, ``online_kernel`` or
> > >   	% echo online > /sys/devices/system/memory/auto_online_blocks
> > > +Similarly to manual onlining, with ``online`` the kernel will select the
> > > +target zone automatically, depending on the configured ``online_policy``.
> > > +
> > >   Modifying the auto-online behavior will only affect all subsequently added
> > >   memory blocks only.
> > > @@ -393,9 +395,11 @@ command line parameters are relevant:
> > >   ======================== =======================================================
> > >   ``memhp_default_state``	 configure auto-onlining by essentially setting
> > >                            ``/sys/devices/system/memory/auto_online_blocks``.
> > > -``movable_node``	 configure automatic zone selection in the kernel. When
> > > -			 set, the kernel will default to ZONE_MOVABLE, unless
> > > -			 other zones can be kept contiguous.
> > > +``movable_node``	 configure automatic zone selection in the kernel when
> > > +			 using the ``contig-zones`` online policy. When
> > > +			 set, the kernel will default to ZONE_MOVABLE when
> > > +			 onlining a memory block, unless other zones can be kept
> > > +			 contiguous.
> > 
> > The movable_node main purpose is to allow unplugging an entire node. Zone
> > selection is a consequence of this. You may want to cite the description of
> > movable_node in kernel-paramenters.txt here.
> 
> Right, I only document the effects of these parameters on memory
> hot(un)plug.
> 
> What about:
> 
> diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst
> b/Documentation/admin-guide/mm/memory-hotplug.rst
> index c20a2c0031cf..f8976ded0863 100644
> --- a/Documentation/admin-guide/mm/memory-hotplug.rst
> +++ b/Documentation/admin-guide/mm/memory-hotplug.rst
> @@ -402,6 +402,9 @@ command line parameters are relevant:
>                          contiguous.
>  ========================
> =======================================================
> 
> +See Documentation/admin-guide/kernel-parameters.txt for a more generic
> +description of these command line parameters.
> +

Ok.

>  Module Parameters
>  ------------------
> 
> 
> > 
> > And, pardon my ignorance, how movable_node will play with auto-movable
> > policy?
> 
> 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 ;-)

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2021-10-07  7:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30 14:41 [PATCH v1 0/3] memory-hotplug.rst: document the "auto-movable" online policy 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 [this message]
2021-10-08  8:33         ` 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=YV6jpoVERotn/New@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --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 \
    /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;
as well as URLs for NNTP newsgroup(s).