Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
From: Dave Hansen <dave.hansen@linux.intel.com>
Date: 2018-10-01 16:24:44
Also in:
linux-acpi, linux-mm
How should a policy in user space look like when new memory gets added - on s390x? Not onlining paravirtualized memory is very wrong.
Because we're going to balloon it away in a moment anyway? We have auto-onlining. Why isn't that being used on s390?
So the type of memory is very important here to have in user space. Relying on checks like "isS390()", "isKVMGuest()" or "isHyperVGuest()" to decide whether to online memory and how to online memory is wrong. Only some specific memory types (which I call "normal") are to be handled by user space. For the other ones, we exactly know what to do: - standby? don't online
I think you're horribly conflating the software desire for what the stae should be and the hardware itself.
quoted
As for the OOM issues, that sounds like something we need to fix by refusing to do (or delaying) hot-add operations once we consume too much ZONE_NORMAL from memmap[]s rather than trying to indirectly tell userspace to hurry thing along.That is a moving target and doing that automatically is basically impossible.
Nah. We know how much metadata we've allocated. We know how much ZONE_NORMAL we are eating. We can *easily* add something to add_memory() that just sleeps until the ratio is not out-of-whack.
You can add a lot of memory to the movable zone and everything is fine. Suddenly a lot of processes are started - boom. MOVABLE should only every be used if you expect an unplug. And for paravirtualized devices, a "typical" unplug does not exist.
No, it's more complicated than that. People use MOVABLE, for instance, to allow more consistent huge page allocations. It's certainly not just hot-remove.