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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090415094433.GA32116@elte.hu>
Date:	Wed, 15 Apr 2009 11:44:33 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Zhaolei <zhaolei@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Tom Zanussi <tzanussi@...il.com>, linux-kernel@...r.kernel.org,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 5/4] ftrace, workqueuetrace: display work name

* KOSAKI Motohiro <kosaki.motohiro@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/