linux-kernel - Re: [linus:master] [mm] f822a9a81a: stress-ng.bigheap.realloc_calls_per

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: <CAG48ez1vM35DZ=kTSd4+ndgR6y33AodLLC2KbfbhGrkDaqdnNQ@mail.gmail.com>
Date: Thu, 7 Aug 2025 20:07:18 +0200
From: Jann Horn <jannh@...gle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, kernel test robot <oliver.sang@...el.com>, 
	Dev Jain <dev.jain@....com>, oe-lkp@...ts.linux.dev, lkp@...el.com, 
	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, 
	Barry Song <baohua@...nel.org>, Pedro Falcato <pfalcato@...e.de>, 
	Anshuman Khandual <anshuman.khandual@....com>, Bang Li <libang.li@...group.com>, 
	Baolin Wang <baolin.wang@...ux.alibaba.com>, bibo mao <maobibo@...ngson.cn>, 
	Hugh Dickins <hughd@...gle.com>, Ingo Molnar <mingo@...nel.org>, Lance Yang <ioworker0@...il.com>, 
	Liam Howlett <liam.howlett@...cle.com>, Matthew Wilcox <willy@...radead.org>, 
	Peter Xu <peterx@...hat.com>, Qi Zheng <zhengqi.arch@...edance.com>, 
	Ryan Roberts <ryan.roberts@....com>, Vlastimil Babka <vbabka@...e.cz>, 
	Yang Shi <yang@...amperecomputing.com>, Zi Yan <ziy@...dia.com>, linux-mm@...ck.org
Subject: Re: [linus:master] [mm] f822a9a81a: stress-ng.bigheap.realloc_calls_per_sec
 37.3% regression

On Thu, Aug 7, 2025 at 8:02 PM David Hildenbrand <david@...hat.com> wrote:
> Sure, we could use pte_batch_hint(), but I'm curious if x86 would also
> benefit with larger folios (e.g., 64K, 128K) with this patch.

Where would you expect such a benefit to come from? This function is
more or less a memcpy(), except it has to read PTEs with xchg(), write
them atomically, and set softdirty flags. For x86, what the associated
folios look like and whether the PTEs are contiguous shouldn't matter.