lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ