On Thu, May 04, 2017 at 10:44:34AM -0700, Dave Hansen wrote: > > From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > > There are a number of times that we loop over NR_MEM_SECTIONS, > looking for section_present() on each section. But, when we have > very large physical address spaces (large MAX_PHYSMEM_BITS), > NR_MEM_SECTIONS becomes very large, making the loops quite long. > > With MAX_PHYSMEM_BITS=46 and a section size of 128MB, the current > loops are 512k iterations, which we barely notice on modern > hardware. But, raising MAX_PHYSMEM_BITS higher (like we will see > on systems that support 5-level paging) makes this 64x longer and > we start to notice, especially on slower systems like simulators. > A 10-second delay for 512k iterations is annoying. But, a 640- > second delay is crippling. > > This does not help if we have extremely sparse physical address > spaces, but those are quite rare. We expect that most of the > "slow" systems where this matters will also be quite small and > non-sparse. > > To fix this, we track the highest section we've ever encountered. > This lets us know when we will *never* see another > section_present(), and lets us break out of the loops earlier. > > Doing the whole for_each_present_section_nr() macro is probably > overkill, but it will ensure that any future loop iterations that > we grow are more likely to be correct. > > Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > Cc: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> Tested-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> It shaved almost 40 seconds from boot time in qemu with 5-level paging enabled for me :) -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
