David asked me if there is a way of checking split_huge_page_test results instead of the existing smap check[1]. This patchset uses kpageflags to get after-split folio orders for a better split_huge_page_test result check. The added gather_folio_orders() scans through a VPN range and collects the numbers of folios at different orders. check_folio_orders() compares the result of gather_folio_orders() to a given list of numbers of different orders.
split_huge_page_test needs the FORCE_READ fix in [2] to work correctly.
This patchset also: 1. added new order and in folio offset to the split huge page debugfs's pr_debug()s; 2. changed split_huge_pages_pid() to skip the rest of a folio if it is split by folio_split() (not changing split_folio_to_order() part since split_pte_mapped_thp test relies on its behavior).
[1] https://lore.kernel.org/linux-mm/e2f32bdb-e4a4-447c-867c-31405cbba151@redhat... [2] https://lore.kernel.org/linux-mm/20250805175140.241656-1-ziy@nvidia.com/
Zi Yan (4): mm/huge_memory: add new_order and offset to split_huge_pages*() pr_debug. mm/huge_memory: move to next folio after folio_split() succeeds. selftests/mm: add check_folio_orders() helper. selftests/mm: check after-split folio orders in split_huge_page_test.
mm/huge_memory.c | 22 +-- .../selftests/mm/split_huge_page_test.c | 67 ++++++--- tools/testing/selftests/mm/vm_util.c | 139 ++++++++++++++++++ tools/testing/selftests/mm/vm_util.h | 2 + 4 files changed, 200 insertions(+), 30 deletions(-)