On Wed, Nov 28, 2018 at 08:47:29AM +0000, Wei Yang wrote: >> >>Dave, >> >>Thanks for your comment :-) >> >>I should put more words to the reason for removing the lock. >> >>Here is a simplified call trace for sparse_add_one_section() during >>physical add/remove phase. >> >> __add_memory() >> add_memory_resource() >> mem_hotplug_begin() >> >> arch_add_memory() >> add_pages() >> __add_pages() >> __add_section() >> sparse_add_one_section(pfn) >> >> mem_hotplug_done() >> >>When we just look at the sparse section initialization, we can see the >>contention happens when __add_memory() try to add a same range or range >>overlapped in SECTIONS_PER_ROOT number of sections. Otherwise, they >>won't access the same memory. >> >>If this happens, we may face two contentions: >> >> * reallocation of mem_section[root] >> * reallocation of memmap and usemap >> >>While neither of them could be protected by the pgdat_resize_lock from >>my understanding. Grab pgdat_resize_lock just slow down the process, >>while finally they will replace the mem_section[root] and >>ms->section_mem_map with their own new allocated data. >> > >Hmm... sorry, I am not correct here. > >The pgdat_resize_lock do protect the second case. > >But not the first one. > One more thing, (hope I am not too talkative) Expand the pgdat_resize_lock to include sparse_index_init() may not work. Because SECTIONS_PER_ROOT number of section may span two nodes. -- Wei Yang Help you, Help me
