Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

Michal Hocko [off-list ref] writes:

On Fri 24-02-17 17:09:13, Vitaly Kuznetsov wrote:

quoted

I have a smal  guest and I want to add more memory to it and the
result is ... OOM. Not something I expected.

Which is not all that unexpected if you use a technology which has to
allocated in order to add more memory.

My point is: why should users care about this? It's our problem that we
can't always hotplug memory. And I think this problem is solvable.

quoted

While this will most probably work for me I still disagree with the
concept of 'one size fits all' here and the default 'false' for ACPI,
we're taking away the feature from KVM/Vmware folks so they'll again
come up with the udev rule which has known issues.

Well, AFAIU acpi_memory_device_add is a standard way how to announce
physical memory added to the system. Where does the KVM/VMware depend on
this to do memory ballooning?

As far as I understand memory hotplug in KVM/VMware is pure ACPI memory
hotplug, there is no specific code for it.

-- 
  Vitaly

On Fri 24-02-17 17:40:25, Vitaly Kuznetsov wrote:

Michal Hocko [off-list ref] writes:

quoted

On Fri 24-02-17 17:09:13, Vitaly Kuznetsov wrote:

[...]

quoted

quoted

While this will most probably work for me I still disagree with the
concept of 'one size fits all' here and the default 'false' for ACPI,
we're taking away the feature from KVM/Vmware folks so they'll again
come up with the udev rule which has known issues.

Well, AFAIU acpi_memory_device_add is a standard way how to announce
physical memory added to the system. Where does the KVM/VMware depend on
this to do memory ballooning?

As far as I understand memory hotplug in KVM/VMware is pure ACPI memory
hotplug, there is no specific code for it.

VMware has its ballooning driver AFAIK and I have no idea what KVM uses.
Anyway, acpi_memory_device_add is no different from doing a physical
memory hotplug IIUC so there shouldn't be any difference to how it is
handled.

I will post the patch as an RFC sometimes next week, let's see what
others think about it.
-- 
Michal Hocko
SUSE Labs