On Fri, Jan 03, 2020 at 09:05:54PM +0800, Wei Yang wrote: > On Fri, Jan 03, 2020 at 03:18:46PM +0800, Wei Yang wrote: > >On Tue, Dec 24, 2019 at 06:28:56AM +0800, Wei Yang wrote: > >>When page is not NULL, function is called by try_to_unmap_one() with > >>TTU_SPLIT_HUGE_PMD set. There are two cases to call try_to_unmap_one() > >>with TTU_SPLIT_HUGE_PMD set: > >> > >> * unmap_page() > >> * shrink_page_list() > >> > >>In both case, the page passed to try_to_unmap_one() is PageHead() of the > >>THP. If this page's mapping address in process is not HPAGE_PMD_SIZE > >>aligned, this means the THP is not mapped as PMD THP in this process. > >>This could happen when we do mremap() a PMD size range to an un-aligned > >>address. > >> > >>Currently, this case is handled by following check in __split_huge_pmd() > >>luckily. > >> > >> page != pmd_page(*pmd) > >> > >>This patch checks the address to skip some work. > > > >I am sorry to forget address Kirill's comment in 1st version. > > > >The first one is the performance difference after this change for a PTE > >mappged THP. > > > >Here is the result:(in cycle) > > > > Before Patched > > > > 963 195 > > 988 40 > > 895 78 > > > >Average 948 104 > > > >So the change reduced 90% time for function split_huge_pmd_address(). Right. But do we have a scenario, where the performance of split_huge_pmd_address() matters? I mean, it it called as part of rmap walk, attempt to split huge PMD where we don't have huge PMD should be within noise. > >For the 2nd comment, the vma check. Let me take a further look to analysis. > > > >Thanks for Kirill's suggestion. > > > > For 2nd comment, check vma could hold huge page. > > You mean do this check ? > > vma->vm_start <= address && vma->vm_end >= address + HPAGE_PMD_SIZE > > This happens after munmap a partial of the THP range? After doing so, we can > skip split_pmd for this case. Okay, you are right. This kind of check would not be safe as we split_huge_pmd_address() after adjusting VMA with expectation of splitting PMD on boundary of the VMA. -- Kirill A. Shutemov
