Hi Alex, On Thu, Apr 30, 2020 at 02:43:28PM -0700, Alexander Duyck wrote: > On 4/30/2020 1:11 PM, Daniel Jordan wrote: > > padata will soon divide up pfn ranges between threads when parallelizing > > deferred init, and deferred_init_maxorder() complicates that by using an > > opaque index in addition to start and end pfns. Move the index outside > > the function to make splitting the job easier, and simplify the code > > while at it. > > > > deferred_init_maxorder() now always iterates within a single pfn range > > instead of potentially multiple ranges, and advances start_pfn to the > > end of that range instead of the max-order block so partial pfn ranges > > in the block aren't skipped in a later iteration. The section alignment > > check in deferred_grow_zone() is removed as well since this alignment is > > no longer guaranteed. It's not clear what value the alignment provided > > originally. > > > > Signed-off-by: Daniel Jordan <daniel.m.jordan@xxxxxxxxxx> > > So part of the reason for splitting it up along section aligned boundaries > was because we already had an existing functionality in deferred_grow_zone > that was going in and pulling out a section aligned chunk and processing it > to prepare enough memory for other threads to keep running. I suspect that > the section alignment was done because normally I believe that is also the > alignment for memory onlining. I think Pavel added that functionality, maybe he could confirm. My impression was that the reason deferred_grow_zone aligned the requested order up to a section was to make enough memory available to avoid being called on every allocation. > With this already breaking things up over multiple threads how does this > work with deferred_grow_zone? Which thread is it trying to allocate from if > it needs to allocate some memory for itself? I may not be following your question, but deferred_grow_zone doesn't allocate memory during the multithreading in deferred_init_memmap because the latter sets first_deferred_pfn so that deferred_grow_zone bails early. > Also what is to prevent a worker from stop deferred_grow_zone from bailing > out in the middle of a max order page block if there is a hole in the middle > of the block? deferred_grow_zone remains singlethreaded. It could stop in the middle of a max order block, but it can't run concurrently with deferred_init_memmap, as per above, so if deferred_init_memmap were to init 'n free the remaining part of the block, the previous portion would have already been initialized.
