Re: [PATCH v2] arm64: implement support for static call trampolines

From: Quentin Perret <qperret@google.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>, Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] arm64: implement support for static call trampolines
Date: Mon, 16 Nov 2020 10:18:02 +0000	[thread overview]
Message-ID: <20201116101802.GA3908597@google.com> (raw)
In-Reply-To: <20201029115442.GA4092571@google.com>

On Thursday 29 Oct 2020 at 11:54:42 (+0000), Quentin Perret wrote:
> The reason I'm interested in this is because Android makes heavy use of
> trace points/hooks, so any potential improvement in this area would be
> welcome. Now I agree we need numbers to show the benefit is real before
> this can be considered for inclusion in the kernel. I'll try and see if
> we can get something.

Following up on this as we've just figured out what was causing
performance issues in our use-case. Basically, we have a setup where
some modules attach to trace hooks for a few things (e.g. the pelt
scheduler hooks + other Android-specific hooks), and that appeared to
cause up ~6% perf regression on the Androbench benchmark.

The bulk of the regression came from a feature that is currently
Android-specific but should hopefully make it upstream (soon?): Control
Flow Integrity (CFI) -- see [1] for more details. In essence CFI is a
software-based cousin of BTI, which is basically about ensuring the
target of an indirect function call has a compatible prototype. This can
be relatively easily checked for potential targets that are known at
compile-time, but is a little harder when the targets are dynamically
loaded, hence causing extra overhead when the target is in a module.

Anyway, I don't think any of the above is particularly relevant to
upstream just yet, but I figured this would interesting to share. The
short-term fix for Android was to locally disable CFI checks around the
trace hooks that cause the perf regression, but I think static-calls
would be a preferable alternative to that (I'll try to confirm that
experimentally). And when/if CFI makes it upstream, then that may become
relevant to upstream as well, though the integration of CFI and
static-calls is not very clear yet.

Thanks,
Quentin

[1] https://www.youtube.com/watch?v=0Bj6W7qrOOI

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel