Re: [PATCH] mm, sparse: drop pgdat_resize_lock in sparse_add/remove_one_section()

[Wei Yang <richard.weiyang@gmail.com>]

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