[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3a21a41b-6062-4c81-8b83-c4b922fcbbd1@redhat.com>
Date: Mon, 27 Oct 2025 20:27:37 +0100
From: David Hildenbrand <david@...hat.com>
To: Zhang Qilong <zhangqilong3@...wei.com>, akpm@...ux-foundation.org,
lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
rppt@...nel.org, surenb@...gle.com, mhocko@...e.com, jannh@...gle.com,
pfalcato@...e.de
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
wangkefeng.wang@...wei.com, sunnanyong@...wei.com
Subject: Re: [RFC PATCH 2/3] mm/mincore: Use can_pte_batch_count() in
mincore_pte_range() for pte batch mincore_pte_range()
On 27.10.25 15:03, Zhang Qilong wrote:
> In current mincore_pte_range(), if pte_batch_hint() return one
> pte, it's not efficient, just call new added can_pte_batch_count().
>
> In ARM64 qemu, with 8 CPUs, 32G memory, a simple test demo like:
> 1. mmap 1G anon memory
> 2. write 1G data by 4k step
> 3. mincore the mmaped 1G memory
> 4. get the time consumed by mincore
>
> Tested the following cases:
> - 4k, disabled all hugepage setting.
> - 64k mTHP, only enable 64k hugepage setting.
>
> Before
>
> Case status | Consumed time (us) |
> ----------------------------------|
> 4k | 7356 |
> 64k mTHP | 3670 |
>
> Pathed:
>
> Case status | Consumed time (us) |
> ----------------------------------|
> 4k | 4419 |
> 64k mTHP | 3061 |
>
I assume you're only lucky in that benchmark because you got consecutive
4k pages / 64k mTHP from the buddy, right?
So I suspect that this will mostly just make a micro benchmark happy,
because the reality where we allocate randomly over time, for the PCP,
etc will look quite different.
--
Cheers
David / dhildenb
Powered by blists - more mailing lists