[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200910133854.GA8713@linux>
Date: Thu, 10 Sep 2020 15:39:00 +0200
From: Oscar Salvador <osalvador@...e.de>
To: Michal Hocko <mhocko@...e.com>
Cc: Laurent Dufour <ldufour@...ux.ibm.com>, akpm@...ux-foundation.org,
David Hildenbrand <david@...hat.com>, rafael@...nel.org,
nathanl@...ux.ibm.com, cheloha@...ux.ibm.com,
stable@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: don't rely on system state to detect hot-plug
operations
On Thu, Sep 10, 2020 at 02:48:47PM +0200, Michal Hocko wrote:
> > Is there any actual usecase for a configuration like this? What is the
> > point to statically define additional memory like this when the same can
> > be achieved on the same command line?
Well, for qemu I am not sure, but if David is right, it seems you can face
the same if you reboot a vm with hotplugged memory.
Moreover, it seems that the problem we spotted with [1], it was a VM running on
Promox (KVM).
The Hypervisor probably said at boot time "Ey, I do have these ACPI devices, care
to enable them now"?
As always, there are all sorts of configurations/scenarios out there in the wild.
> Forgot to ask one more thing. Who is going to online that memory when
> userspace is not running yet?
Depends, if you have CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE set or you specify
memhp_default_online_type=[online,online_*], memory will get onlined right
after hot-adding stage:
/* online pages if requested */
if (memhp_default_online_type != MMOP_OFFLINE)
walk_memory_blocks(start, size, NULL, online_memory_block);
If not, systemd-udev will do the magic once the system is up.
--
Oscar Salvador
SUSE L3
Powered by blists - more mailing lists