Messages in this thread | | | Subject | Re: [PATCH v2 0/4] Static calls | From | Andy Lutomirski <> | Date | Tue, 4 Dec 2018 15:41:01 -0800 |
| |
> On Dec 4, 2018, at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> 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.
| |