Re: [RFC PATCH 16/22 -v2] add get_monotonic_cycles

[Mathieu Desnoyers]

* Frank Ch. Eigler (fche@xxxxxxxxxx) 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/