On Mon, Apr 11, 2022 at 02:47:26PM +0530, Anshuman Khandual wrote: > > > On 4/5/22 14:08, Muchun Song wrote: > > On Tue, Apr 5, 2022 at 12:44 PM Anshuman Khandual > > <anshuman.khandual@xxxxxxx> wrote: > >> > >> > >> > >> On 3/31/22 12:26, Muchun Song wrote: > >>> 1st concern: > >>> ''' > >>> But what happens when a hot remove section's vmemmap area (which is > >>> being teared down) is nearby another vmemmap area which is either created > >>> or being destroyed for HugeTLB alloc/free purpose. As you mentioned > >>> HugeTLB pages inside the hot remove section might be safe. But what about > >>> other HugeTLB areas whose vmemmap area shares page table entries with > >>> vmemmap entries for a section being hot removed ? Massive HugeTLB alloc > >>> /use/free test cycle using memory just adjacent to a memory hotplug area, > >>> which is always added and removed periodically, should be able to expose > >>> this problem. > >>> ''' > >>> > >>> Answer: At the time memory is removed, all HugeTLB pages either have been > >>> migrated away or dissolved. So there is no race between memory hot remove > >>> and free_huge_page_vmemmap(). Therefore, HugeTLB pages inside the hot > >>> remove section is safe. Let's talk your question "what about other > >> > >> HugeTLB pages inside the memory range is safe but concern is about the > >> vmemmap mapping for the HugeTLB which might share intermediate entries > >> with vmemmap mapping for the memory range/section being removed. > > > > The shared page table level only could be PMD, PUD and PGD, the PTE > > page table cannot be shared with other sections, and we only exchange > > PTEs for vmemmap mapping. > > Right, the shared entries (if any) are not at the leaf level. > > > > >> > >>> HugeTLB areas whose vmemmap area shares page table entries with vmemmap > >>> entries for a section being hot removed ?", the question is not > >> > >> Right. > >> > >>> established. The minimal granularity size of hotplug memory 128MB (on > >>> arm64, 4k base page), any HugeTLB smaller than 128MB is within a section, > >>> then, there is no share PTE page tables between HugeTLB in this section > >> > >> 128MB is the hot removable granularity but, its corresponding vmemmap > >> range is smaller i.e (128MB/4K) * sizeof(struct page). Memory section > >> getting hot removed (its vmemmap mapping being teared down) along with > >> HugeTLB (on another section) vmemmap remap operation, could not collide > >> while inside vmemmap mapping areas on init_mm ? > > > > The boundary address of a section is aligned with 128MB and its > > corresponding vmemmap boundary address is aligned with 2MB > > which is mapped with a separated PTE page table (or a PMD entry). > > Even if these PMD entries split during HugeTLB remapping, they will not > conflict with another memory section being removed simultaneously. Also > any shared page table pages will not be freed, during memory hot remove > operation as vmemmap remap does not delete any entries. > > But just wondering if during PMD slit and PTE page table page addition, > these PMD entries could not be empty, even temporarily ? > The pmd entry is either a PTE page table or a PMD leaf entry, it cannot be a empty entry forever. More details can refer to __split_vmemmap_huge_pmd(). Thanks.
