linux-kernel - Re: [PATCH] arm64/lib: copy

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]

Date: Wed, 26 Jun 2024 19:50:57 +0800
From: Jisheng Zhang <jszhang@...nel.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Will Deacon <will@...nel.org>, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64/lib: copy_page: s/stnp/stp

On Mon, Jun 24, 2024 at 06:56:33PM +0100, Catalin Marinas wrote:
> On Thu, Jun 13, 2024 at 08:18:12AM +0800, Jisheng Zhang wrote:
> > stnp performs non-temporal store, give a hints to the memory system
> > that caching is not useful for this data. But the scenario where
> > copy_page() used may not have this implication, although I must admit
> > there's such case where stnp helps performance(good). In this good
> > case, we can rely on the HW write streaming mechanism in some
> > implementations such as cortex-a55 to detect the case and take actions.
> > 
> > testing with https://github.com/apinski-cavium/copy_page_benchmark
> > this patch can reduce the time by about 3% on cortex-a55 platforms.
> 
> What about other CPUs? I'm also not convinced by such microbenchmarks.

Per my test on CA53 and CA73, CA73 got similar improvements. As for CA53
there's no difference, maybe due to the follwoing commit in the ATF:

54035fc4672aa ("Disable non-temporal hint on Cortex-A53/57")

> It looks like it always copies to the same page, the stp may even
> benefit from some caching of the data which we wouldn't need in a real
> scenario.

Yep this is also my understanding where's the improvement from. And
I must admit there's case where stnp helps performance. we can rely
on the HW write streaming mechanism to detect and take actions.

However, sometimes, the "cache" behavior can benefit the scenario. Then
in this case, the stnp here would double lose.

what do you think?

> 
> So, I'm not merging this unless it's backed by some solid data across
> several CPU implementations.
> 
> -- 
> Catalin