Hi Yeoreum!

On 9/2/26 11:26 PM, Yeoreum Yun wrote:
> HPAGE_SIZE and HPAGE_SHIFT macro is written based on the 4KB PAGE_SIZE.
> When this macro is used in some test, test result would be strange in
> the system where PAGE_SIZE is more than 4KB.
>
> Here is example with transhuge-stress test with 16KB PAGE_SIZE:
>
>   transhuge-stress: allocate 61073 transhuge pages, using 122146 MiB virtual 
> memory and 1908 MiB of ram
>     3.292 s/loop, 0.054 ms/page,  37106.002 MiB/s     2566 succeed, 58507 
> failed, 2566 different pages
>     0.591 s/loop, 0.010 ms/page, 206850.792 MiB/s        0 succeed, 61073 
> failed,    0 different pages
>     0.527 s/loop, 0.009 ms/page, 231895.107 MiB/s        0 succeed, 61073 
> failed,    0 different pages
>     0.527 s/loop, 0.009 ms/page, 231839.704 MiB/s        0 succeed, 61073 
> failed,    0 different pages
>     0.528 s/loop, 0.009 ms/page, 231544.782 MiB/s        0 succeed, 61073 
> failed,    0 different pages
>     0.528 s/loop, 0.009 ms/page, 231462.074 MiB/s        0 succeed, 61073 
> failed,    0 different pages
>     0.527 s/loop, 0.009 ms/page, 231770.300 MiB/s        0 succeed, 61073 
> failed,    0 different pages
>     ...
>   ok 1 Completed
>
> Remove the HPAGE_SIZE and HPAGE_SHIFT macro. and introduce hpshift()
> helper to get the HPAGE_SHIFT properly. For HPAGE_SIZE, use pre-exist

Nit : pre-existing

> helper, read_pmd_pagesize().
> > Also, do KSM_MERGE_TIME_HUGE_PAGES test with size of 512 MiB which
> is the LCD pmd_size among 4KB, 16KB and 64KB page_size.
>
> After this patch, output of transhuge-stress:
>
>   transhuge-stress: allocate 3817 transhuge pages, using 122146 MiB virtual 
> memory and 119 MiB of ram
>     2.558 s/loop, 0.670 ms/page,  47755.759 MiB/s     2585 succeed, 1232 
> failed, 2585 different pages
>     2.640 s/loop, 0.692 ms/page,  46268.432 MiB/s     2585 succeed, 1232 
> failed, 2585 different pages
>     2.635 s/loop, 0.690 ms/page,  46360.298 MiB/s     2585 succeed, 1232 
> failed, 2585 different pages
>     2.782 s/loop, 0.729 ms/page,  43899.795 MiB/s     2616 succeed, 1201 
> failed, 2616 different pages
>     2.692 s/loop, 0.705 ms/page,  45380.876 MiB/s     2627 succeed, 1190 
> failed, 2627 different pages
>     2.612 s/loop, 0.684 ms/page,  46765.812 MiB/s     2628 succeed, 1189 
> failed, 2628 different pages
>     2.683 s/loop, 0.703 ms/page,  45520.990 MiB/s     2630 succeed, 1187 
> failed, 2630 different pages
>     2.727 s/loop, 0.714 ms/page,  44789.321 MiB/s     2631 succeed, 1186 
> failed, 2631 different pages
>     ...
>   ok 1 Completed
>
> Suggested-by: Lorenzo Stoakes (ARM) <[email protected]>
> Signed-off-by: Yeoreum Yun <[email protected]>
> ---

[...]

> diff --git a/tools/testing/selftests/mm/vm_util.c 
> b/tools/testing/selftests/mm/vm_util.c
> index 4821a3563036..4332f8fb2104 100644
> --- a/tools/testing/selftests/mm/vm_util.c
> +++ b/tools/testing/selftests/mm/vm_util.c
> @@ -21,6 +21,8 @@
>
>  unsigned int __page_size;
>  unsigned int __page_shift;
> +uint64_t __hpage_size;
> +uint64_t __hpage_shift;

I was wondering, would it make more sense to call these __pmd_pagesize
and __pmd_shift instead?

hpage_size is used at places for mTHPs of arbitrary sizes and these
values come from read_pmd_pagesize(). So calling __hpage_size as the PMD
size seems a bit weird. Also, there is already a pmd_pagesize variable
in vm_util.c, so I feel the PMD specific names would be more consistent.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Reply via email to