Re: [ANNOUNCE] New utility: 'trace'

[Ingo Molnar <mingo@elte.hu>]

* Darren Hart <dvhart@linux.intel.com> wrote:

> On 11/16/2010 01:04 PM, Thomas Gleixner wrote:
> >We are pleased to announce a new tracing tool called 'trace'.
> >
> 
> Hi Thomas, Ingo - Congrats and Thanks!

You are welcome :)

> > At this point we'd like to ask for feedback from other users of tracing tools, 
> > which workflow components would you like to see in addition to what the 'trace' 
> > tool is offering?
> >
> > Comments, bug reports, suggestions welcome,
> 
> The first thing that comes to mind is trace_marker:
> 
>   echo "Test point A" > /sys/kernel/debug/tracing/trace_marker
> 
> I've found this sort of markup to be useful using ftrace (with C equivalents 
> embedded in the test case). Is this supported?

Yes, LatencyTop uses something similar IIRC, via a prctl() hack: it uses 
prctl(PR_SET_NAME) to inject up to 16 characters into the comm - and then every perf 
event gets that comm. You can utilize that straight away if you need a marker 
solution right now.

A cleaner, more generic approach would be a more free-form ASCII event facility for 
this: a generic 'user-space triggered event' with injection capabilities.

To inject it, we could put that into a prctl() as well, for easy, single-syscall 
access from C. We already have two perf prctls: PR_TASK_PERF_EVENTS_DISABLE, 
PR_TASK_PERF_EVENTS_ENABLE - and this would be a third one: PR_TASK_PERF_USER_EVENT.

This would, like the existing perf_event_task_enable()/disable() methods, loop 
through current events and inject a string into matching user events.

Ideally i'd like to see basically user-space access to trace_printk(), and proper 
integration into /debug/tracing/events/ enumeration and availability - not a 
ftrace-specific and admin-only hack like /sys/kernel/debug/tracing/trace_marker is 
today.

Would you be interested in helping out with (and testing) such a more generic 
approach?

Thanks,

	Ingo