> On 9/7/26 10:19, Yeoreum Yun wrote: > > split_huge_page_test can fail for the following reasons: > > > > 1. During the test, khugepaged may collapse previously split pages again, > > causing intermittent failures. > > > > 2. Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on > > AArch64”), > > glibc may call madvise(MADV_HUGEPAGE) for sufficiently large > > allocations > > made by memalign(). The underlying VMA may start at a different address > > from the aligned address returned by memalign(). Moreover, a subsequent > > madvise(MADV_HUGEPAGE) call does not split the VMA because it already > > has the same advice. > > > > This causes the test to fail because the check_huge_xxx() helpers > > incorrectly require the address returned by memalign() to match the > > VMA start address reported in /proc/self/smaps. > > > > Address these issues by applying MADV_NOHUGEPAGE after faulting in the > > huge page, preventing khugepaged from collapsing it again, and instead of > > relying on /proc/self/smaps, use /proc/self/pagemap and > > /proc/kpageflags to detect huge-page mappings and large folios: > > > > 1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of > > using check_large_folios(), since only the mapping type matters. > > This identifies PMD-mapped huge pages. > > 2. Otherwise, use check_large_folios() to detect large folios. This > > covers mTHP cases. > > 3. Check the folio flags according to the type of huge page. > > > > Also, current usage of memalign() would result memory area may > > unexpectedly merge with an adjacent VMA, causing tests > > that inspect it through /proc/self/smaps to fail. > I'm not particularly happy about this. > > Relying on VMA merging details rather hints that we shouldn't be using smaps > to > query some stats/properties. > > Which exact things are test querying through /proc/self/smaps? Could we > convert > the code to just query that stuff through different interfaces?
Well, users currently for using /proc/self/smaps are for check vm-flags: - guard-regions where using check_vmflags_guard() - pfnmap test where uses check_vmflag_pfnmap() AFAIK, there is no interface to get vm-flags except /proc/self/smaps, we should add new interface but I'm not sure whether it's useful except for test purpose. Since for a testing, the most chance for VMA merge is when using anon private mapping and this would be enough with allocate_isolated_mem(). -- Sincerely, Yeoreum Yun
