On Thu, Jul 12, 2018 at 04:37:25PM -0400, Pavel Tatashin wrote: > Changelog: > v5 - v4 > - Fixed the issue that was reported on ppc64 when > CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER is removed > - Consolidated the new buffer allocation between vmemmap > and non-vmemmap variants of sparse layout. > - Removed all review-by comments, because I had to do > significant amount of changes compared to previous version > and need another round of review. > - I also would appreciate if those who reported problems with > PPC64 could test this change. 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. -- Oscar Salvador SUSE L3
