Messages in this thread | | | Date | Sat, 19 Jan 2008 10:29:39 -0500 | From | Mathieu Desnoyers <> | Subject | Re: [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
| |