[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <29A74A26-E922-4A4F-9B4A-8DB0336B99DF@jrtc27.com>
Date: Thu, 6 Feb 2025 01:05:56 +0000
From: Jessica Clarke <jrtc27@...c27.com>
To: "Christoph Lameter (Ampere)" <cl@...two.org>
Cc: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>,
luto@...nel.org,
xin@...or.com,
kirill.shutemov@...ux.intel.com,
palmer@...belt.com,
tj@...nel.org,
andreyknvl@...il.com,
brgerst@...il.com,
ardb@...nel.org,
dave.hansen@...ux.intel.com,
jgross@...e.com,
will@...nel.org,
akpm@...ux-foundation.org,
arnd@...db.de,
corbet@....net,
dvyukov@...gle.com,
richard.weiyang@...il.com,
ytcoode@...il.com,
tglx@...utronix.de,
hpa@...or.com,
seanjc@...gle.com,
paul.walmsley@...ive.com,
aou@...s.berkeley.edu,
justinstitt@...gle.com,
jason.andryuk@....com,
glider@...gle.com,
ubizjak@...il.com,
jannh@...gle.com,
bhe@...hat.com,
vincenzo.frascino@....com,
rafael.j.wysocki@...el.com,
ndesaulniers@...gle.com,
mingo@...hat.com,
catalin.marinas@....com,
junichi.nomura@....com,
nathan@...nel.org,
ryabinin.a.a@...il.com,
dennis@...nel.org,
bp@...en8.de,
kevinloughlin@...gle.com,
morbo@...gle.com,
dan.j.williams@...el.com,
julian.stecklina@...erus-technology.de,
peterz@...radead.org,
kees@...nel.org,
kasan-dev@...glegroups.com,
x86@...nel.org,
linux-arm-kernel@...ts.infradead.org,
linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
llvm@...ts.linux.dev,
linux-doc@...r.kernel.org
Subject: Re: [PATCH 00/15] kasan: x86: arm64: risc-v: KASAN tag-based mode for
x86
On 5 Feb 2025, at 18:51, Christoph Lameter (Ampere) <cl@...two.org> wrote:
>
> On Tue, 4 Feb 2025, Jessica Clarke wrote:
>
>> It’s not “no performance penalty”, there is a cost to tracking the MTE
>> tags for checking. In asynchronous (or asymmetric) mode that’s not too
>
>
> On Ampere Processor hardware there is no penalty since the logic is build
> into the usual read/write paths. This is by design. There may be on other
> platforms that cannot do this.
You helpfully cut out all the explanation of where the performance
penalty comes from. But if it’s as you say I can only assume your
design chooses to stall all stores until they have actually written, in
which case you have a performance cost compared with hardware that
omitted MTE or optimises for non-synchronous MTE. The literature on MTE
agrees that it is not no penalty (but can be low penalty). I don’t
really want to have some big debate here about the ins and outs of MTE,
it’s not the place for it, but I will stand up and point out that
claiming MTE to be “no performance penalty” is misrepresentative of the
truth
Jess
Powered by blists - more mailing lists