> About PPC64, your patchset fixes the issue as the population gets followed by a > sparse_init_one_section(). > > It can be seen here: > > Before: > > kernel: vmemmap_populate f000000000000000..f000000000004000, node 0 > kernel: * f000000000000000..f000000000010000 allocated at (____ptrval____) > kernel: vmemmap_populate f000000000000000..f000000000008000, node 0 > kernel: * f000000000000000..f000000000010000 allocated at (____ptrval____) > kernel: vmemmap_populate f000000000000000..f00000000000c000, node 0 > kernel: * f000000000000000..f000000000010000 allocated at (____ptrval____) > > > After: > > kernel: vmemmap_populate f000000000000000..f000000000004000, node 0 > kernel: * f000000000000000..f000000000010000 allocated at (____ptrval____) > kernel: vmemmap_populate f000000000000000..f000000000008000, node 0 > kernel: vmemmap_populate f000000000000000..f00000000000c000, node 0 > kernel: vmemmap_populate f000000000000000..f000000000010000, node 0 > kernel: vmemmap_populate f000000000010000..f000000000014000, node 0 > kernel: * f000000000010000..f000000000020000 allocated at (____ptrval____) > > > As can be seen, before the patchset, we keep calling vmemmap_create_mapping() even if we > populated that section already, because of vmemmap_populated() checking for SECTION_HAS_MEM_MAP. > > After the patchset, since each population is being followed by a call to sparse_init_one_section(), > when vmemmap_populated() gets called, we have SECTION_HAS_MEM_MAP already in case the section > was populated. Hi Oscar, Right, I also like that this solution removes one extra loop, thus reduces the code size. We were populating pages in one place, and then loop again to set sections, now we do both in one place, but still allow preallocation of memory to reduces fragmentation on all platforms. However, I still wanted to see if someone could test on real hardware. Thank you, Pavel
