* Frank Ch. Eigler ([EMAIL PROTECTED]) 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
