On Fri 13-04-18 15:16:24, David Hildenbrand wrote: [...] > In contrast to existing balloon solutions: > - The device is responsible for its own memory only. Please be more specific. Any ballooning driver is responsible for its own memory. So what exactly does that mean? > - Works on a coarser granularity (e.g. 4MB because that's what we can > online/offline in Linux). We are not using the buddy allocator when unplugging > but really search for chunks of memory we can offline. Again, more details please. Virtio driver already tries to scan suitable pages to balloon AFAIK. > - A device can belong to exactly one NUMA node. This way we can online/offline > memory in a fine granularity NUMA aware. What does prevent existing balloon solutions to be NUMA aware? > - Architectures that don't have proper memory hotplug interfaces (e.g. s390x) > get memory hotplug support. I have a prototype for s390x. I am pretty sure that s390 does support memory hotplug. Or what do you mean? > - Once all 4MB chunks of a memory block are offline, we can remove the > memory block and therefore the struct pages (seems to work in my prototype), > which is nice. OK, so our existing ballooning solutions indeed do not free up memmaps which is suboptimal. > Todo: > - We might have to add a parameter to offline_pages(), telling it to not > try forever but abort in case it takes too long. Offlining fails when it see non-migrateable pages but other than that it should always succeed in the finite time. If not then there is a bug to be fixed. -- Michal Hocko SUSE Labs
