On 29.08.19 13:33, David Hildenbrand wrote: > On 29.08.19 10:23, Michal Hocko wrote: >> 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... > > Almost ;) > >> >>> 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. > > Last time I asked whether we can just drop all that nasty > zone->contiguous handling I was being told that it does have a > significant performance impact and is here to stay. The boundaries are a > key component to detect whether a zone is contiguous. > > So yes, while we allow interleaved memory zones, having contiguous zones > is beneficial for performance. That's why also memory onlining code will > try to online memory as default to the zone that will keep/make zones > contiguous. > > Anyhow, I think with this series most of the zone shrinking code becomes > "digestible". Except minor issues with ZONE_DEVICE - which is acceptable. > Also, there are plenty of other users of node_spanned_pages/zone_spanned_pages etc.. I don't think this can go - not that easy :) -- Thanks, David / dhildenb
