Re: [RFC Get rid of shrink code - memory-hotplug]

[osalvador@suse.de]

On 2018-12-07 11:35, osalvador@suse.de wrote:
> On 2018-12-07 11:32, Michal Hocko wrote:
>> On Fri 07-12-18 10:54:50, Vlastimil Babka wrote:
>>> Well, __pageblock_pfn_to_page() has to be called for each pageblock 
>>> in
>>> compaction, when zone_contiguous is false. And that's unchanged since
>>> the introduction of zone_contiguous, so the numbers should still 
>>> hold.
>> 
>> OK, this means that we have to carefully re-evaluate zone_contiguous 
>> for
>> each offline operation.

I started to think about this but some questions arose.

Actually, no matter what we do, if we re-evaluate zone_contiguous
in the offline operation, zone_contiguous will be left unset.

set_zone_contiguous() calls __pageblock_pfn_to_page() in
pageblock_nr_pages chunks to determine if the zone is contiguous,
and checks the following:

* first/end pfn of the pageblock are valid sections
* first pfn of the pageblock is online
* we do not intersect different zones
* first/end pfn belong to the same zone

Now, when dropping the shrink code and re-evaluating zone_contiguous in 
offline
operation, set_zone_contiguous() will return false, leaving us with 
zone_contiguous
unset.

I wonder if we want that, or we want to stick with the optimization that
zone_contiguous brings us.

If we do not care, dropping everything and just calling 
clear_zone_contiguous and
set_zone_contiguous is the right thing to go.
But, if we want to keep the zone_contiguous optimization, I am afraid 
that we need
to re-adjust zone boundaries in the offline operation whenever we remove 
first/end
section.
In that case, set_zone_contiguous will still keep zone_contiguous as 
set.

So, it seems that the only headache we still have is this 
zone_contiguous thing.
Ideas? Suggestions?