Thread (1 message) 1 message, 1 author, 2017-03-13

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

From: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2017-03-13 15:10:49
Also in: linux-acpi, linux-mm, linux-s390, lkml

Michal Hocko [off-list ref] writes:
On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote:
quoted
quoted
What is the API those guests ask for the memory? And who is actually
responsible to ask for that memory? Is it a kernel or userspace
solution?
Whatever, this can even be a system administrator running
'free'.
I am pretty sure that 'free' will not give you additional memory but
let's be serious here... 
If this is solely about monitoring from
userspace and requesting more memory from the userspace then I would
consider arguing about timely hotplug operation as void because there is
absolutely no guarantee to do the request itself in a timely fashion.
quoted
Hyper-V driver sends si_mem_available() and
vm_memory_committed() metrics to the host every second and this can be
later queried by any tool (e.g. powershell script).
And how exactly is this related to the acpi hotplug which you were
arguing needs the timely handling as well?
What I meant to say is that there is no single 'right' way to get memory
usage from a VM, make a decision somewhere (in the hypervisor, on some
other host or even in someone's head) and issue a command to add more
memory. I don't know what particular tools people use with ESX/KVM VMs
but I think that multiple options are available.
quoted
quoted
quoted
With udev-style memory onlining they should be aware of page
tables and other in-kernel structures which require allocation so they
need to add memory slowly and gradually or they risk running into OOM
(at least getting some processes killed and these processes may be
important). With in-kernel memory hotplug everything happens
synchronously and no 'slowly and gradually' algorithm is required in
all tools which may trigger memory hotplug.
What prevents those APIs being used reasonably and only asks so much
memory as they can afford? I mean 1.5% available memory necessary for
the hotplug is not all that much. Or more precisely what prevents to ask
for this additional memory in a synchronous way?
The knowledge about the fact that we need to add memory slowly and
wait till it gets onlined is not obvious.
yes it is and we cannot afford to give a better experience with the
implementation that requires to have memory to online a memory.
Actually, we need memory to add memory, not to online it. And as I said
before, this is a real issue which requires addressing, it should always
be possible to add more memory (and to online already added memory if
these events are separated).
quoted
AFAIR when you hotplug memory
to Windows VMs there is no such thing as 'onlining', and no brain is
required, a simple script 'low memory -> add mory memory' always
works. Asking all these script writers to think twice before issuing a
memory add command memory sounds like too much (to me).
Pardon me, but not requiring a brain while doing something on Windows
VMs is not really an argument...
Why? Windows (or any other OS) is just an example that things can be
done in a different way, otherwise we'll end up with arguments like "it
was always like that in Linux so it's good".

-- 
  Vitaly

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help