Re: [PATCH v4 24/26] arm64: mte: Introduce early param to disable MTE support
From: Szabolcs Nagy <hidden>
Date: 2020-05-27 10:38:01
Also in:
linux-arch, linux-mm
The 05/27/2020 10:55, Will Deacon wrote:
On Tue, May 26, 2020 at 07:11:53PM -0700, Patrick Daly wrote:quoted
On Fri, May 22, 2020 at 11:37:15AM +0100, Catalin Marinas wrote:quoted
The actual question here is what the on/off behaviour is needed for. We can figure out the best mechanism for this once we know what we want to achieve. My wild guess above was performance analysis but that can be toggled by either kernel boot parameter or run-time sysctl (or just the Kconfig option). If it is about forcing user space not to use MTE, we may look into some other sysctl controls (we already have one for the tagged address ABI).We want to allow the end user to be able to easily "opt out" of MTE in favour of better power, perf and battery life.Who is "the end user" in this case? If MTE is bad enough for power, performance and battery life that we need a kill switch, then perhaps we shouldn't enable it by default and the few people that want to use it can build a kernel with it enabled. However, then I don't really see what MTE buys you over the existing KASAN implementations. I thought the general idea was that you could run in the (cheap) "async" mode, and then re-run in the more expensive "sync" mode to further diagnose any failures. That model seems to work well with these patches, since reporting is disabled by default. Are you saying that there is a significant penalty incurred even when reporting is not enabled? Anyway, we don't offer global runtime/cmdline switches for the vast majority of other architectural features -- instead, we choose a sensible default, and I think we should do the same here.
i would not expect mte overhead if userspace processes don't map anything with PROT_MTE and don't enable tag checking with prctl. (i.e. userspace runtimes can "opt out" of mte for better power, perf and battery) is that not the case? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel