From: Zi Yan <ziy@nvidia.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: David Hildenbrand <david@redhat.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Nico Pache <npache@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Vlastimil Babka <vbabka@suse.cz>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 3/4] selftests/mm: add check_folio_orders() helper.
Date: Thu, 07 Aug 2025 13:02:31 -0400 [thread overview]
Message-ID: <898EC7C6-8AFE-4CED-AED7-C59C5CC03EB6@nvidia.com> (raw)
In-Reply-To: <dd2118cd-9209-43d5-9c73-8e3989931841@linux.alibaba.com>
On 7 Aug 2025, at 2:49, Baolin Wang wrote:
> On 2025/8/6 10:20, Zi Yan wrote:
>> The helper gathers an folio order statistics of folios within a virtual
>> address range and checks it against a given order list. It aims to provide
>> a more precise folio order check instead of just checking the existence of
>> PMD folios.
>>
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> ---
>> tools/testing/selftests/mm/vm_util.c | 139 +++++++++++++++++++++++++++
>> tools/testing/selftests/mm/vm_util.h | 2 +
>> 2 files changed, 141 insertions(+)
>>
>> diff --git a/tools/testing/selftests/mm/vm_util.c b/tools/testing/selftests/mm/vm_util.c
>> index 9dafa7669ef9..373621145b2a 100644
>> --- a/tools/testing/selftests/mm/vm_util.c
>> +++ b/tools/testing/selftests/mm/vm_util.c
>> @@ -17,6 +17,12 @@
>> #define STATUS_FILE_PATH "/proc/self/status"
>> #define MAX_LINE_LENGTH 500
>> +#define PGMAP_PRESENT (1UL << 63)
>> +#define KPF_COMPOUND_HEAD (1UL << 15)
>> +#define KPF_COMPOUND_TAIL (1UL << 16)
>> +#define KPF_THP (1UL << 22)
>> +#define PFN_MASK ((1UL<<55)-1)
>> +
>> unsigned int __page_size;
>> unsigned int __page_shift;
>> @@ -338,6 +344,139 @@ int detect_hugetlb_page_sizes(size_t sizes[], int max)
>> return count;
>> }
>> +static int get_page_flags(uint64_t vpn, int pagemap_file, int kpageflags_file,
>> + uint64_t *flags)
>> +{
>> + uint64_t pfn;
>> + size_t count;
>> +
>> + count = pread(pagemap_file, &pfn, sizeof(pfn),
>> + vpn * sizeof(pfn));
>> +
>> + if (count != sizeof(pfn))
>> + return -1;
>> +
>> + /*
>> + * Treat non-present page as a page without any flag, so that
>> + * gather_folio_orders() just record the current folio order.
>> + */
>> + if (!(pfn & PGMAP_PRESENT)) {
>> + *flags = 0;
>> + return 0;
>> + }
>
> It looks like you can reuse the helper pagemap_get_pfn() in this file?
Sure.
>
>> +
>> + count = pread(kpageflags_file, flags, sizeof(*flags),
>> + (pfn & PFN_MASK) * sizeof(*flags));
>> +
>> + if (count != sizeof(*flags))
>> + return -1;
>> +
>> + return 0;
>> +}
>> +
>> +static int gather_folio_orders(uint64_t vpn_start, size_t nr_pages,
>
> In this file, other helper functions use userspace virtual address as parameters, so can we consistently use virtual address for calculations instead of the 'vpn_start'?
>
Sure.
>> + int pagemap_file, int kpageflags_file,
>> + int orders[], int nr_orders)
>> +{
>> + uint64_t page_flags = 0;
>> + int cur_order = -1;
>> + uint64_t vpn;
>> +
>> + if (!pagemap_file || !kpageflags_file)
>> + return -1;
>> + if (nr_orders <= 0)
>> + return -1;
>> +
>> + for (vpn = vpn_start; vpn < vpn_start + nr_pages; ) {
>> + uint64_t next_folio_vpn;
>> + int status;
>> +
>> + if (get_page_flags(vpn, pagemap_file, kpageflags_file, &page_flags))
>> + return -1;
>> +
>> + /* all order-0 pages with possible false postive (non folio) */
>> + if (!(page_flags & (KPF_COMPOUND_HEAD | KPF_COMPOUND_TAIL))) {
>> + orders[0]++;
>> + vpn++;
>> + continue;
>> + }
>> +
>> + /* skip non thp compound pages */
>> + if (!(page_flags & KPF_THP)) {
>> + vpn++;
>> + continue;
>> + }
>> +
>> + /* vpn points to part of a THP at this point */
>> + if (page_flags & KPF_COMPOUND_HEAD)
>> + cur_order = 1;
>> + else {
>> + /* not a head nor a tail in a THP? */
>> + if (!(page_flags & KPF_COMPOUND_TAIL))
>> + return -1;
>> + continue;
>> + }
>> +
>> + next_folio_vpn = vpn + (1 << cur_order);
>> +
>> + if (next_folio_vpn >= vpn_start + nr_pages)
>> + break;
>> +
>> + while (!(status = get_page_flags(next_folio_vpn, pagemap_file,
>> + kpageflags_file,
>> + &page_flags))) {
>> + /* next compound head page or order-0 page */
>> + if ((page_flags & KPF_COMPOUND_HEAD) ||
>> + !(page_flags & (KPF_COMPOUND_HEAD |
>> + KPF_COMPOUND_TAIL))) {
>> + if (cur_order < nr_orders) {
>> + orders[cur_order]++;
>> + cur_order = -1;
>> + vpn = next_folio_vpn;
>> + }
>> + break;
>> + }
>> +
>> + /* not a head nor a tail in a THP? */
>> + if (!(page_flags & KPF_COMPOUND_TAIL))
>> + return -1;
>> +
>> + cur_order++;
>> + next_folio_vpn = vpn + (1 << cur_order);
>> + }
>> +
>> + if (status)
>> + return status;
>> + }
>> + if (cur_order > 0 && cur_order < nr_orders)
>> + orders[cur_order]++;
>> + return 0;
>> +}
>> +
>> +int check_folio_orders(uint64_t vpn_start, size_t nr_pages, int pagemap_file,
>> + int kpageflags_file, int orders[], int nr_orders)
>> +{
>> + int vpn_orders[nr_orders];
>
> IIRC, we should avoid using VLA (variable length arrays)?
OK. I can change it to malloc.
Thanks.
>
>> + int status;
>> + int i;
>> +
>> + memset(vpn_orders, 0, sizeof(int) * nr_orders);
>> + status = gather_folio_orders(vpn_start, nr_pages, pagemap_file,
>> + kpageflags_file, vpn_orders, nr_orders);
>> + if (status)
>> + return status;
>> +
>> + status = 0;
>> + for (i = 0; i < nr_orders; i++)
>> + if (vpn_orders[i] != orders[i]) {
>> + ksft_print_msg("order %d: expected: %d got %d\n", i,
>> + orders[i], vpn_orders[i]);
>> + status = -1;
>> + }
>> +
>> + return status;
>> +}
>> +
>> /* If `ioctls' non-NULL, the allowed ioctls will be returned into the var */
>> int uffd_register_with_ioctls(int uffd, void *addr, uint64_t len,
>> bool miss, bool wp, bool minor, uint64_t *ioctls)
>> diff --git a/tools/testing/selftests/mm/vm_util.h b/tools/testing/selftests/mm/vm_util.h
>> index b55d1809debc..dee9504a6129 100644
>> --- a/tools/testing/selftests/mm/vm_util.h
>> +++ b/tools/testing/selftests/mm/vm_util.h
>> @@ -85,6 +85,8 @@ bool check_huge_shmem(void *addr, int nr_hpages, uint64_t hpage_size);
>> int64_t allocate_transhuge(void *ptr, int pagemap_fd);
>> unsigned long default_huge_page_size(void);
>> int detect_hugetlb_page_sizes(size_t sizes[], int max);
>> +int check_folio_orders(uint64_t vpn_start, size_t nr_pages, int pagemap_file,
>> + int kpageflags_file, int orders[], int nr_orders);
>> int uffd_register(int uffd, void *addr, uint64_t len,
>> bool miss, bool wp, bool minor);
--
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2025-08-07 17:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-06 2:20 [PATCH 0/4] Better split_huge_page_test result check Zi Yan
2025-08-06 2:20 ` [PATCH 1/4] mm/huge_memory: add new_order and offset to split_huge_pages*() pr_debug Zi Yan
2025-08-06 12:42 ` David Hildenbrand
2025-08-06 16:51 ` Lorenzo Stoakes
2025-08-07 6:50 ` Baolin Wang
2025-08-06 2:20 ` [PATCH 2/4] mm/huge_memory: move to next folio after folio_split() succeeds Zi Yan
2025-08-06 12:47 ` David Hildenbrand
2025-08-06 14:29 ` Zi Yan
2025-08-07 8:45 ` Wei Yang
2025-08-07 17:04 ` Zi Yan
2025-08-07 8:55 ` Wei Yang
2025-08-07 17:05 ` Zi Yan
2025-08-08 3:15 ` Wei Yang
2025-08-08 15:24 ` Zi Yan
2025-08-08 15:44 ` Zi Yan
2025-08-06 2:20 ` [PATCH 3/4] selftests/mm: add check_folio_orders() helper Zi Yan
2025-08-07 3:00 ` wang lian
2025-08-07 17:00 ` [PATCH " Zi Yan
2025-08-07 6:49 ` Baolin Wang
2025-08-07 17:02 ` Zi Yan [this message]
2025-08-06 2:20 ` [PATCH 4/4] selftests/mm: check after-split folio orders in split_huge_page_test Zi Yan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=898EC7C6-8AFE-4CED-AED7-C59C5CC03EB6@nvidia.com \
--to=ziy@nvidia.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=npache@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®