Re: [PATCH v3 00/11] mm/memory_hotplug: Shrink zones before removing memory

[Michal Hocko <mhocko@kernel.org>]

On Thu 29-08-19 09:00:08, David Hildenbrand wrote:
> This is the successor of "[PATCH v2 0/6] mm/memory_hotplug: Consider all
> zones when removing memory". I decided to go one step further and finally
> factor out the shrinking of zones from memory removal code. Zones are now
> fixed up when offlining memory/onlining of memory fails/before removing
> ZONE_DEVICE memory.

I was about to say Yay! but then reading...

> Example:
> 
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
>         spanned  0
>         present  0
>         managed  0
> :/# echo "online_movable" > /sys/devices/system/memory/memory41/state 
> :/# echo "online_movable" > /sys/devices/system/memory/memory43/state
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
>         spanned  98304
>         present  65536
>         managed  65536
> :/# echo 0 > /sys/devices/system/memory/memory43/online
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
>         spanned  32768
>         present  32768
>         managed  32768
> :/# echo 0 > /sys/devices/system/memory/memory41/online
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
>         spanned  0
>         present  0
>         managed  0

... this made me realize that you are trying to fix it instead. Could
you explain why do we want to do that? Why don't we simply remove all
that crap? Why do we even care about zone boundaries when offlining or
removing memory? Zone shrinking was mostly necessary with the previous
onlining semantic when the zone type could be only changed on the
boundary or unassociated memory. We can interleave memory zones now
arbitrarily.
-- 
Michal Hocko
SUSE Labs