lkml.org 
[lkml]   [2008]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 16/22 -v2] add get_monotonic_cycles
    * Frank Ch. Eigler (fche@redhat.com) wrote:
    > Hi -
    >
    > On Fri, Jan 18, 2008 at 10:55:27PM -0500, Steven Rostedt wrote:
    > > [...]
    > > > All this complexity is to be justified by keeping the raw prev/next
    > > > pointers from being sent to a naive tracer? It seems to me way out of
    > > > proportion.
    > >
    > > Damn, and I just blew away all my marker code for something like this ;-)
    >
    > Sorry! :-)
    >
    > > [...]
    > > We have in sched.c the following marker:
    > > trace_mark(kernel_sched_scheduler, "prev %p next %p", prev, next);
    >
    > Fine so far!
    >
    > > Then Mathieu can add in some code somewhere (or a module, or something)
    > > ret = marker_probe_register("kernel_sched_scheduler",
    > > "prev %p next %p",
    > > pretty_print_sched_switch, NULL);
    >
    > > static void pretty_print_sched_switch(const struct marker *mdata,
    > > void *private_data,
    > > const char *format, ...)
    > > {
    > > [...]
    > > trace_mark(kernel_pretty_print_sched_switch,
    > > "prev_pid %d next_pid %d prev_state %ld",
    > > prev->pid, next->pid, prev->state);
    > > }
    >
    > That marker_probe_register call would need to be done only when the
    > embedded (k_p_p_s_s) marker is actually being used. Otherwise we'd
    > lose all the savings of a dormant sched.c marker by always calling
    > into pretty_print_sched_switch(), whether or not the k_p_p_s_s marker
    > was active.
    >
    > In any case, if the naive tracer agrees to become educated about some
    > of these markers in the form of intermediary functions like that, they
    > need not insist on a second hop through marker territory anyway:
    >
    > static void pretty_print_sched_switch(const struct marker *mdata,
    > void *private_data,
    > const char *format, ...)
    > {
    > [...]
    > lttng_backend_trace(kernel_pretty_print_sched_switch,
    > "prev_pid %d next_pid %d prev_state %ld",
    > prev->pid, next->pid, prev->state);
    > }
    >

    Oh! perfect then :) Since I already planned my ltt-marker-control kernel
    module to connect specialized callbacks instead of the dumb one, it
    shouldn't be so hard to do.

    I would just have to find another way to declare the trace events (it's
    currently embedded in the markers), but it's not a showstopper. I'll try
    this.

    Thanks to you both for the good proposals,

    Mathieu

    >
    > - FChE

    --
    Mathieu Desnoyers
    Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


    \
     
     \ /
      Last update: 2008-01-19 16:33    [W:0.027 / U:1.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site