Re: [PATCH v2 0/4] Static calls
From: Andy Lutomirski
Date: Tue Dec 04 2018 - 18:41:07 EST
> On Dec 4, 2018, at 3:08 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
>
> Where did this end up BTW?
>
> I know that there's controversy about the
> CONFIG_HAVE_STATIC_CALL_OPTIMIZED option, but I don't think the
> CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED version was controversial. From the
> v1 patch 0 description:
>
> There are three separate implementations, depending on what the arch
> supports:
>
> 1) CONFIG_HAVE_STATIC_CALL_OPTIMIZED: patched call sites - requires
> objtool and a small amount of arch code
>
> 2) CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED: patched trampolines - requires
> a small amount of arch code
>
> 3) If no arch support, fall back to regular function pointers
>
> My benchmarks showed the best improvements with the
> STATIC_CALL_OPTIMIZED, but it still showed improvement with the
> UNOPTIMIZED version as well. Can we at least apply 2 and 3 from the
> above (which happen to be the first part of the patch set. 1 comes in
> at the end).
Sounds good to me.
>
> I would also just call it CONFIG_STATIC_CALL. If we every agree on the
> optimized version, then we can call it CONFIG_STATIC_CALL_OPTIMIZED.
> Have an option called UNOPTIMIZED just seems wrong.
My objection to all the bike shed colors so far is that we *always* have static_call() â itâs just not always static.
Anyway, I have a new objection to Joshâs create_gap proposal: what on Earth will kernel CET do to it? Maybe my longjmp-like hack is actually better.