Michal Hocko <mhocko@xxxxxxxxxx> writes: > On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote: >> > >> > 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. > >> 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. >> >> 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). > >> 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 from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
