From: Peter Zijlstra <peterz@infradead.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Josh Poimboeuf <jpoimboe@redhat.com>,
Jason Baron <jbaron@akamai.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [RFC PATCH] powerpc: Investigate static_call concept
Date: Fri, 27 Aug 2021 16:18:47 +0200 [thread overview]
Message-ID: <YSj0R6g6HeboSk9n@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <8077899fee81f08a7dffbf185569d3a1f7a2ab68.1630057495.git.christophe.leroy@csgroup.eu>
On Fri, Aug 27, 2021 at 09:45:37AM +0000, Christophe Leroy wrote:
> This RFC is to validate the concept of static_call on powerpc.
>
> Highly copied from x86.
>
> It replaces ppc_md.get_irq() which is called at every IRQ, by
> a static call.
The code looks saner, but does it actually improve performance? I'm
thinking the double branch also isn't free.
> When updating the call, we just replace the instruction at the
> trampoline address by a relative jump to the function.
>
> For the time being, the case of out-of-range functions is not handled.
The paranoid in me would've made it:
BUG_ON(patch_branch(...));
just to make sure to notice the target not fitting. Ohh, patch_branch()
doesn't return the create_branch() error, perhaps that wants to be
fixed?
Did you see the arm64 variant that deals with out-of-range functions in
their trampoline?
https://lore.kernel.org/linux-arm-kernel/20201120082103.4840-1-ardb@kernel.org/
Not exactly 'nice' but supposedly that works.
> +#define ARCH_DEFINE_STATIC_CALL_NULL_TRAMP(name) \
> + asm(".pushsection .text, \"ax\" \n" \
> + ".align 4 \n" \
> + ".globl " STATIC_CALL_TRAMP_STR(name) " \n" \
> + STATIC_CALL_TRAMP_STR(name) ": \n" \
> + " blr \n" \
> + ".type " STATIC_CALL_TRAMP_STR(name) ", @function \n" \
> + ".size " STATIC_CALL_TRAMP_STR(name) ", . - " STATIC_CALL_TRAMP_STR(name) " \n" \
> + ".popsection \n")
> +
Since you support CALL_NULL_TRAMP, your patch function below:
> +void arch_static_call_transform(void *site, void *tramp, void *func, bool tail)
> +{
> + mutex_lock(&text_mutex);
> +
> + if (tramp)
> + patch_branch(tramp, (unsigned long)func, 0);
> +
> + mutex_unlock(&text_mutex);
> +}
> +EXPORT_SYMBOL_GPL(arch_static_call_transform);
Ought to patch in "blr" when !func to be consistent :-)
I'm thinking that your core kernel text all fits in the native range and
only modules need out-of-range ?
next prev parent reply other threads:[~2021-08-27 14:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-27 9:45 Christophe Leroy
2021-08-27 14:18 ` Peter Zijlstra [this message]
2021-08-27 16:04 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YSj0R6g6HeboSk9n@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=ardb@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=christophe.leroy@csgroup.eu \
--cc=jbaron@akamai.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®