[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC] mm/memory_hotplug: Introduce memory block types

On 01/10/2018 18:24, Dave Hansen wrote:
>> 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?

No, rether somebody wanted this VM to have more memory, so it should use
it - basically what HyperV or XEN also do. (in contrast to the concept
of standby memory on s390).

> > We have auto-onlining.  Why isn't that being used on s390?

Do you mean the sys parameter? How would that help?

>> 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.

Agreed, user space should be able to configure it.

>>> 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.

As noted in the other thread, that's a good point. We have to allow to
make a decision in user space.

I agree to your initial proposal to distinguish "standby" from
"auto-online". It would allow to have sane defaults in user space.



David / dhildenb

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.