On Tue, Jan 07, 2020 at 03:03:33PM +0300, Kirill A. Shutemov wrote: >On Fri, Jan 03, 2020 at 10:01:28PM +0800, Wei Yang wrote: >> On Fri, Jan 03, 2020 at 04:26:50PM +0300, Kirill A. Shutemov wrote: >> >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. >> >> Sorry for my poor English. >> >> I don't catch the meaning of the last sentence. "within noise" here means >> non-huge PMD is an expected scenario and we could tolerate this? > >Basically, I doubt that this change would bring any measurable perfromance >benefits on a real workload. > Ok, let's leave it now. >-- > Kirill A. Shutemov -- Wei Yang Help you, Help me
