Messages in this thread | | | Date | Wed, 5 Dec 2018 09:04:22 -0600 | From | Josh Poimboeuf <> | Subject | Re: [PATCH v2 0/4] Static calls |
| |
On Tue, Dec 04, 2018 at 03:41:01PM -0800, Andy Lutomirski wrote: > > > > 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.
(Poking my head up for a bit, soon to disappear again until next week)
Ard had already objected to "unoptimized", which was why for v2 I renamed them to CONFIG_STATIC_CALL_OUTLINE and CONFIG_STATIC_CALL_INLINE.
I could rename it to CONFIG_STATIC_CALL and CONFIG_STATIC_CALL_INLINE if you prefer. I don't have much of an opinion either way.
I'll post a v3 next week or so, with the controversial bits more fully separated from the non-controversial bits. So at least the out-of-line implementation can get merged.
> My objection to all the bike shed colors so far is that we *always* > have static_call() — it’s just not always static.
Hm? Do you mean you don't like that we have a generic function pointer implementation? or what?
> 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.
Does CET even care about iret? I assumed it didn't. If it does, your proposal would have the same problem, no?
-- Josh
| |