> On 9/10/26 12:54, Yeoreum Yun wrote: > >> On 9/7/26 10:19, Yeoreum Yun wrote: > >>> 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(). Furthermore, a subsequent > >>> madvise(MADV_HUGEPAGE) call does not split the VMA because the flag is > >>> already set. > >>> > >>> This causes split_huge_page_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. > >>> > >>> 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. > >>> > >>> Suggested-by: David Hildenbrand (Arm) <[email protected]> > >>> Suggested-by: Zi Yan <[email protected]> > >>> Reviewed-by: Zi Yan <[email protected]> > >>> Reviewed-by: Baolin Wang <[email protected]> > >>> Tested-by: Baolin Wang <[email protected]> > >>> Acked-by: Lorenzo Stoakes (ARM) <[email protected]> > >>> Signed-off-by: Yeoreum Yun <[email protected]> > >>> --- > >>> tools/testing/selftests/mm/vm_util.c | 145 > >>> ++++++++++++++++++++++------------- > >>> tools/testing/selftests/mm/vm_util.h | 1 + > >>> 2 files changed, 92 insertions(+), 54 deletions(-) > >>> > >>> diff --git a/tools/testing/selftests/mm/vm_util.c > >>> b/tools/testing/selftests/mm/vm_util.c > >>> index 4821a3563036..dc62ce84e143 100644 > >> > >> [...] > >> > >>> > >>> - if (hpage_size == pmd_pagesize) > >>> - return __check_pmd_huge(addr, "AnonHugePages: ", nr_hpages, > >>> hpage_size); > >>> +static bool check_huge_type(uint64_t categories, uint64_t kpageflags, > >>> + enum check_huge_type type) > >>> +{ > >>> + const bool file = categories & PAGE_IS_FILE; > >>> + const bool swapbacked = kpageflags & KPF_SWAPBACKED; > >>> + > >>> + switch (type) { > >>> + case CHECK_HUGE_ANON: > >>> + return !file; > >>> + case CHECK_HUGE_FILE: > >>> + return file && !swapbacked; > >>> + case CHECK_HUGE_SHMEM: > >>> + return file & swapbacked; > >>> + } > >> > >> Why do we even need CHECK_HUGE_SHMEM? > >> > >> That's really just a legacy thing for using smaps to identify huge pages. > >> > >> It's sufficient to identify CHECK_HUGE_FILE if you know that you have > >> shmem mapping. > >> > >> You will not arbitrarily have non-shmem folios in a shmem mapping :) > > > > Agree. but there seems the case where discern whethr the mapping is > > with regular file or shmem like tmpfs -- khugepaged test where using > > __shmem_ops. So I think it would be better to keep this as-is. > > Let's not add or maintain unnecessary complexity. > > hmem_check_huge can really just become check_huge_file. > > Even file_check_huge can just be simplified. > > There must be a pretty good reason why we'd want to keep this.
Okay. then I'll change the check_huge_shmem() to check_huge_file() with the separate patch. -- Sincerely, Yeoreum Yun
