lkml.org 
[lkml]   [2009]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 5/4] ftrace, workqueuetrace: display work name

* 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


\
 
 \ /
  Last update: 2009-04-15 11:49    [from the cache]
©2003-2011 Jasper Spaans