Re: [PATCH v2 0/4] Static calls

[Andy Lutomirski]

> 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.