Re: [PATCH 4/4] perf tools: Complete support for dynamic strings

[Ingo Molnar <mingo@elte.hu>]

* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> On Mon, Aug 31, 2009 at 10:11:33AM +0200, Ingo Molnar wrote:
> > 
> > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > 
> > > Complete support for __str_loc type strings of ftrace events which
> > > have dynamic offsets values set for each of them inside their sammples.
> > > 
> > > Before:
> > >         geany-5759  [000]     0.000000: lock_release: name
> > >         geany-5759  [000]     0.000000: lock_release: name
> > >         geany-5759  [000]     0.000000: lock_release: name
> > >   kondemand/0-362   [000]     0.000000: lock_release: name
> > >       pdflush-421   [000]     0.000000: lock_release: name
> > > 
> > > After:
> > >         geany-5759  [000]     0.000000: lock_release: &u->lock
> > >         geany-5759  [000]     0.000000: lock_release: key
> > >         geany-5759  [000]     0.000000: lock_release: &group->notification_mutex
> > >   kondemand/0-362   [000]     0.000000: lock_release: &rq->lock
> > >       pdflush-421   [000]     0.000000: lock_release: &rq->lock
> > 
> > I've applied all five patches, thanks Frederic!
> > 
> > Also, i think this makes perf trace quite functional already so i 
> > merged that topic (and these commits) into tracing/core, for v2.6.32 
> > merging.
> 
> 
> 
> Ok.
> 
> 
>  
> > One thing that i noticed which is still quite quirky are the 
> > parameters to perf record. (needing -R and the :r postfix to events) 
> > Could something more intuitive be done here?
> 
> 
> I hope. It's not that easy, at least for me, to find something intuitive
> there.
> 
> I've thought about
> 
>   -e *sys:event  (because the * suggests a deref that takes the content)
>                  But that's a bit convoluted. And moreover we may want
>                  to support basic regex later for event selection.
> 
> If someone has an idea, please tell me.
> 
> Another thing. We could, by default display a small comment while
> selecting an event without its content:
> 
> "Opening counter sys:event. Type -R if you want raw sampling."
> 
> The user could shut that up with a -q option.

The confusion comes from the multi-purpose nature of 'perf record'. 
It is not clear from that workflow whether the resulting perf.data 
will be for trace reporting or for profiling/call-graph analysis.

I think we could solve some of this confusion by always gathering 
the most information we can - and allow the user to trim down the 
data if he wants to.

I.e. PERF_SAMPLE_RAW should be implicit if tracepoints are 
specified.

An additional measure would be to simplify the tracing workflow: a 
simple 'perf trace -e sched:switch /bin/ls' should really do 
implicit recording and should report the trace after that.

	Ingo