On 10/31/18 12:05 PM, Alexander Duyck wrote: > On Wed, 2018-10-31 at 15:40 +0000, Pasha Tatashin wrote: >> >> On 10/17/18 7:54 PM, Alexander Duyck wrote: >>> This patch introduces a new iterator for_each_free_mem_pfn_range_in_zone. >>> >>> This iterator will take care of making sure a given memory range provided >>> is in fact contained within a zone. It takes are of all the bounds checking >>> we were doing in deferred_grow_zone, and deferred_init_memmap. In addition >>> it should help to speed up the search a bit by iterating until the end of a >>> range is greater than the start of the zone pfn range, and will exit >>> completely if the start is beyond the end of the zone. >>> >>> This patch adds yet another iterator called >>> for_each_free_mem_range_in_zone_from and then uses it to support >>> initializing and freeing pages in groups no larger than MAX_ORDER_NR_PAGES. >>> By doing this we can greatly improve the cache locality of the pages while >>> we do several loops over them in the init and freeing process. >>> >>> We are able to tighten the loops as a result since we only really need the >>> checks for first_init_pfn in our first iteration and after that we can >>> assume that all future values will be greater than this. So I have added a >>> function called deferred_init_mem_pfn_range_in_zone that primes the >>> iterators and if it fails we can just exit. >>> >>> On my x86_64 test system with 384GB of memory per node I saw a reduction in >>> initialization time from 1.85s to 1.38s as a result of this patch. >>> >>> Signed-off-by: Alexander Duyck <alexander.h.duyck@xxxxxxxxxxxxxxx> >> >> Hi Alex, >> >> Could you please split this patch into two parts: >> >> 1. Add deferred_init_maxorder() >> 2. Add memblock iterator? >> >> This would allow a better bisecting in case of problems. Chaning two >> loops into deferred_init_maxorder() while a good idea, is still >> non-trivial and might lead to bugs. >> >> Thank you, >> Pavel > > I can do that, but I will need to flip the order. I will add the new > iterator first and then deferred_init_maxorder. Otherwise the > intermediate step ends up being too much throw-away code. That sounds good. Thank you, Pavel > > - Alex >
