lkml.org 
[lkml]   [2009]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Stupid tracepoint ideas
    * Steven Rostedt (rostedt@goodmis.org) wrote:
    >
    > On Mon, 20 Apr 2009, Mathieu Desnoyers wrote:
    >
    > > * Steven Rostedt (rostedt@goodmis.org) wrote:
    > > >
    > > > Mathieu,
    > > >
    > > > You may have tried this in your creation of tracepoints, but I figured I
    > > > would ask before wasting too much time on it.
    > > >
    > > > I'm looking at ways to make tracepoints even lighter weight when disabled.
    > > > And I thought of doing section code. I'm playing with the following idea
    > > > (see below patch) but I'm afraid gcc is allowed to think that the code it
    > > > produces will not move to different sections.
    > > >
    > > > Any thoughts on how we could do something similar to this.
    > > >
    > > > Note, this patch is purely proof-of-concept. I'm fully aware that it is an
    > > > x86 solution only.
    > > >
    > > > -- Steve
    > > >
    > > > [ no Signed-off-by: because this patch is crap ]
    > > >
    > > > diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
    > > > index 4353f3f..6953f78 100644
    > > > --- a/include/linux/tracepoint.h
    > > > +++ b/include/linux/tracepoint.h
    > > > @@ -65,9 +65,18 @@ struct tracepoint {
    > > > extern struct tracepoint __tracepoint_##name; \
    > > > static inline void trace_##name(proto) \
    > > > { \
    > > > - if (unlikely(__tracepoint_##name.state)) \
    > > > + if (unlikely(__tracepoint_##name.state)) { \
    > > > + asm volatile ("jmp 43f\n" \
    > > > + "42:\n" \
    > > > + ".section .unlikely,\"ax\"\n" \
    > > > + "43:\n" \
    > > > + ::: "memory"); \
    > > > __DO_TRACE(&__tracepoint_##name, \
    > > > - TP_PROTO(proto), TP_ARGS(args)); \
    > > > + TP_PROTO(proto), TP_ARGS(args)); \
    > > > + asm volatile ("jmp 42b\n" \
    > > > + ".previous\n" \
    > > > + ::: "memory"); \
    > > > + } \
    > >
    > > You are right, I thought of this.
    > >
    > > gcc forbids jumping outside of inline assembly statements. Optimisations
    > > done by gcc are not aware of this sort of execution flow modification,
    > > and gcc has every rights to interleave unrelated code between the two
    > > inline assembly statements.
    >
    > Yeah, I was afraid of that :-/
    >
    > Would be nice to apply sections to code:
    >
    > __attribute__((section ".unlikely")) {
    > /* code for .unlikely section */
    > }
    >
    > And have gcc do the jmps to and from the section.
    >
    > This should not be too hard to implement.
    >

    Yes, but for some reason no kernel developer I know seems to be very
    keen of digging into gcc's internals. :-)

    > >
    > > And is it me or this sounds like an infinite loop ?
    > >
    > > 42:
    > > ....
    > > jmp 42b
    > >
    >
    > Nope:
    >
    > jmp 43f
    > 42:
    > .section ...
    > 43:
    > jmp 42b
    > .previous
    >
    > is the same as:
    >
    > jmp 43f
    > 42:
    > [...]
    >
    >
    > in the other section:
    >
    > 43:
    > jmp 42b
    >
    > same as a return.
    >

    Ah ! I knew I had to be missing something :)

    Mathieu


    > -- Steve
    >

    --
    Mathieu Desnoyers
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


    \
     
     \ /
      Last update: 2009-04-20 23:15    [W:2.876 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site