Re: [PATCH v2 5/4] ftrace, workqueuetrace: display work name

[Ingo Molnar <mingo@elte.hu>]

* KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:

> > About event tracing, we want to have something that let us 
> > identifying the events individually. For the works it can be 
> > either the function embedeed in the work, or the work itself. 
> > But do we need both? Since it's rare that a function can be 
> > embedeed in more than two works, I guess we only need one of 
> > those informations. Which one is the more efficient to identify 
> > a work? That can be discussed actually.
> 
> OK. I think function name is enough. I'll drop this patch.

I think function name is what we generally use - and maybe that fits 
better into the function tracer concepts as well.

The 'work' (worklet) itself can often be non-symbolic: some 
dynamically allocated object embedded in another dynamically 
allocated object.

It might make sense to trace it (non-symbolically - just as a 
pointer value) - because to the work flow itself we can see what got 
started and where, and where it got finished, by looking at the work 
object itself.

In other words: the work function is the 'actor' or method, the 
worklet is the 'object'. They are two separate entities and tracing 
_both_ makes sense - as long as it's pervasive enough to understand 
the full life cycle of a worklet:

   worklet initialization (optional)
   queueing
   start of execution
   completion
   destruction/cancellation (optional)

It does not make sense to just trace bits of the life cycle.

Once we have these events instrumented, we can use them to build 
various derived metrics: average latency of queueing, average 
execution time, ratio of execution versus cancellation, etc. etc. We 
can build histograms that summarize informaton, or we can expose the 
full raw and uncut trace history as well.

All of that builds on a complete capture of the essentials of a 
subsystem.

> And also function name has another benefit. symbol name is module 
> unload safe. then we don't need to care module unloading.
> 
> In the other hand, work_struct variable is often static variable. 
> it mean the variable name is often very short.

That is true - but often a worklet is dynamic and then we'll have no 
symbol name to work with at all.

	Ingo