[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c170282b-be66-4eb0-91bf-17614acf3321@lucifer.local>
Date: Thu, 7 Aug 2025 20:52:45 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Jann Horn <jannh@...gle.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 07, 2025 at 08:31:18PM +0200, David Hildenbrand wrote:
> On 07.08.25 20:07, Jann Horn wrote:
> > 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.
> >
>
> Good point, I was assuming TLB flushing as well, but that doesn't really
> apply here because we are already batching that.
Ah good point, but indeed, while we force a TLB flush if we discover a
present pte, we do so only _after_ we have finished processing entries in
the PTE table, and we would only batch up to, at most, the end of the PTE
table, so we have zero possible delta here on that.
I did wonder if _somehow_ we'd get some benefit by grouping operations
(yes, this was a handwavey thought).
But Jann's point puts that to bed...
I really feel like this is a super arch-specfic feature that maybe we need
to go around and make arm64-only or predicated on something like the
contpte hint check to be effectively equivalent to.
Because my whole basis for accepting this on other arches is there'd be
little to no impact and now we have seen a huge impact and it's worrying.
>
> --
> Cheers,
>
> David / dhildenb
>
Cheers, Lorenzo
Powered by blists - more mailing lists