lkml.org 
[lkml]   [2018]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH RFC 0/3] Static calls
    On Sun, Nov 11, 2018 at 9:02 PM Ingo Molnar <mingo@kernel.org> wrote:
    >
    >
    > * Josh Poimboeuf <jpoimboe@redhat.com> wrote:
    >
    > > On Fri, Nov 09, 2018 at 08:28:11AM +0100, Ingo Molnar wrote:
    > > > > - I'm not sure about the objtool approach. Objtool is (currently)
    > > > > x86-64 only, which means we have to use the "unoptimized" version
    > > > > everywhere else. I may experiment with a GCC plugin instead.
    > > >
    > > > I'd prefer the objtool approach. It's a pretty reliable first-principles
    > > > approach while GCC plugin would have to be replicated for Clang and any
    > > > other compilers, etc.
    > >
    > > The benefit of a plugin is that we'd only need two of them: GCC and
    > > Clang. And presumably, they'd share a lot of code.
    > >
    > > The prospect of porting objtool to all architectures is going to be much
    > > more of a daunting task (though we are at least already considering it
    > > for some arches).
    >
    > Which architectures would benefit from ORC support the most?
    >
    > I really think that hard reliance on GCC plugins is foolish - but maybe
    > Clang's plugin infrastructure is a guarantee that it remains a sane and
    > usable interface.
    >
    > > > I'd be very happy with a demonstrated paravirt optimization already -
    > > > i.e. seeing the before/after effect on the vmlinux with an x86 distro
    > > > config.
    > > >
    > > > All major Linux distributions enable CONFIG_PARAVIRT=y and
    > > > CONFIG_PARAVIRT_XXL=y on x86 at the moment, so optimizing it away as much
    > > > as possible in the 99.999% cases where it's not used is a primary
    > > > concern.
    > >
    > > For paravirt, I was thinking of it as more of a cleanup than an
    > > optimization. The paravirt patching code already replaces indirect
    > > branches with direct ones -- see paravirt_patch_default().
    > >
    > > Though it *would* reduce the instruction footprint a bit, as the 7-byte
    > > indirect calls (later patched to 5-byte direct + 2-byte nop) would
    > > instead be 5-byte direct calls to begin with.
    >
    > Yes.

    It would be a huge cleanup IMO -- the existing PVOP call stuff is
    really quite ugly IMO. Also, the existing stuff tries to emulate the
    semantics of passing parameters of unknown types using asm
    constraints, and I just don't believe that GCC does what we want it to
    do. In general, passing the *value* of a pointer to asm doesn't seem
    to convince gcc that the pointed-to value is used by the asm, and this
    makes me nervous. See commit 715bd9d12f84d8f5cc8ad21d888f9bc304a8eb0b
    as an example of this. In a similar vein, the existing PVOP calls
    have a "memory" clobber, and that's not free.

    \
     
     \ /
      Last update: 2018-11-12 06:35    [W:2.892 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site