Re: [PATCH RFC 0/8] mm: online/offline 4MB chunks controlled by device driver

[Michal Hocko <mhocko@kernel.org>]

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