[lkml]   [2018]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 0/4] Static calls

> On Dec 4, 2018, at 3:08 PM, Steven Rostedt <> 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.

 \ /
  Last update: 2018-12-05 00:41    [W:0.221 / U:4.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site