linux-kernel - Re: [PATCH] mm: map maximum pages possible in finish

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aYYHGisOQFQINXwR@casper.infradead.org>
Date: Fri, 6 Feb 2026 15:22:02 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Dev Jain <dev.jain@....com>
Cc: akpm@...ux-foundation.org, david@...nel.org, lorenzo.stoakes@...cle.com,
	Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org,
	surenb@...gle.com, mhocko@...e.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, ryan.roberts@....com,
	anshuman.khandual@....com, kirill@...temov.name
Subject: Re: [PATCH] mm: map maximum pages possible in finish_fault

On Fri, Feb 06, 2026 at 07:26:48PM +0530, Dev Jain wrote:
> We test the patch with the following userspace program. A shmem VMA of
> 2M is created, and faulted in, with sysfs setting
> hugepages-2048k/shmem_enabled = always, so that the pagecache is populated
> with a 2M folio. Then, a 64K VMA is created, and we fault on each page.
> Then, we do MADV_DONTNEED to zap the pagetable, so that we can fault again
> in the next iteration. We measure the accumulated time taken during
> faulting the VMA.
> 
> On arm64,
> 
> without patch:
> Total time taken by inner loop: 4701721766 ns
> 
> with patch:
> Total time taken by inner loop: 516043507 ns
> 
> giving a 9x improvement.

It's nice that you can construct a test-case that shows improvement, but
is there any real workload that benefits from this?