On Thu, May 07, 2020 at 02:18:42PM -0700, Alexander Duyck wrote: > The idea behind merging ranges it to address possible cases where a > range is broken up such that there is a hole in a max order block as a > result. Gah, yes, you're right, there could be multiple ranges in a max order block, so the threads have to use the zone iterators to skip the holes. > By combining the ranges if they both span the same section we > can guarantee that the entire section will be initialized as a block > and not potentially have partially initialized sections floating > around. Without that mo_pfn logic I had in there I was getting panics > every so often when booting up one of my systems as I recall. > > Also the iterator itself is cheap. It is basically just walking a > read-only list so it scales efficiently as well. One of the reasons Agreed, it's not expensive, it's just gnarliness I was hoping to avoid, but obviously it's not gonna work. > why I arranged the code the way I did is that it also allowed me to > get rid of an extra check in the code as the previous code was having > to verify if the pfn belonged to the node. That is all handled > directly through the for_each_free_mem_pfn_range_in_zone[_from] call > now. > > > With the series as it stands plus leaving in the section alignment check in > > deferred_grow_zone (which I think could be relaxed to a maxorder alignment > > check) so it doesn't stop mid-max-order-block, threads simply deal with a > > start/end range and deferred_init_maxorder becomes shorter and simpler too. > > I still think we are better off initializing complete sections since > the pageblock_flags are fully initialized that way as well. Fair enough. > What > guarantee do you have that all of the memory ranges will be max order > aligned? Sure, it's a problem with multiple ranges in a maxorder block, the rest could've been handled. > The problem is we have to guarantee all pages are initialized > before we start freeing the pages in a max order page. If we just > process each block as-is I believe we can end up with some > architectures trying to access uninitialized memory in the buddy > allocator as a result. That is why the deferred_init_maxorder function > will walk through the iterator, using the _from version to avoid > unnecessary iteration, the first time initializing the pages it needs > to cross that max order boundary, and then again to free the max order > block of pages that have been initialized. The iterator itself is > farily cheap and only has to get you through the smaller ranges before > you end up at the one big range that it just kind of sits at while it > is working on getting it processed. Right. Ok, I think we're on the same page for the next version. Thanks for the thorough review!
