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: <20090415141250.AC46.A69D9226@jp.fujitsu.com>
Date:	Wed, 15 Apr 2009 15:13:17 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	kosaki.motohiro@...fujitsu.com, Zhaolei <zhaolei@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Tom Zanussi <tzanussi@...il.com>, Ingo Molnar <mingo@...e.hu>,
	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

Hi

> Kosaki-san,
> 
> Perhaps you misunderstood me, which is easy because my english is
> evil ;-)

hehe, my english is poor much than you ;)


> We have to distinguish event tracing and statistical/histogram tracing
> here.
> 
> Event tracing is about logging the events when they come and store
> them one by one to output them later. That's what does TRACE_EVENT
> for instance.
> 
> Statistical tracing doesn't store a trace of each event but instead
> update some numbers after each event: number of events, maximum
> latency, average, etc...

Agreed.


> 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.

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.


> When I talked about per-work tracing, it was in a generic way. What do we
> use to identify each work individually: either the function or the work
> name? Both seems accurate for that actually, the fact is that both can
> be used for per-work tracing.
> 
> Actually my previous mails were focused on statistical tracing.
> 
> You proposed something that would result in the following final view:
> 
> 	workqueue_name:pid	n_inserted n_executed cpu max_latency
> 
> And then by looking at the trace file, we can retrieve the work/function
> that produced this max latency.
> 
> While I proposed this another idea:
> 
> 	workqueue_name:pid	n_inserted n_executed cpu
> 
> 	work1	latency_avg	latency_max
> 	work2	latency_avg	latency_max
> 	work3	latency_avg	latency_max
> 	.....
> 
> (We can have it with one file per workqueue).
> work1 can be either the work name or the function executed though
> the function is probably the main focus here because it's the
> real source culprit.
> But we can also output work_name:func
> 
> You see? With such output we see immediately which works are creating the
> worst latencies.
> And the event tracing is still very helpful here to have a more
> fine grained tracing and see the behaviour of some works more precisely.
> 
> That's a kind of tracing process we can imagine:
> 
> - we start by looking at the statistics and indentify the wicked
>   works/funcs.
> - we look at the events on /debug/tracing/trace and, coupling with
>   some well-chosen filters, we observe the behaviour of a work with
>   more precision.
> 
> 
> But I'm not opposite to your patch, I think it can be helpful to also
> have the work name on certain circumstances.
> But it makes the whole line a bit messy with a lot of informations for
> those who only need the func name (or only the work name).
> The best would be to have a runtime option to choose whether we want
> to display it or not.

I understand you mean. thanks.
My conclusion is follow,

Conclusion:
 1/4	resend, but remove __entry->work
 2/4	resend
 3/4	remake as your suggestion
 4/4	remake as your suggestion
 5/4	dropped

but unfortunately I don't have enough development time. then,
I and Zhaolei discuss this issue and we agreed Zaholei develop it.


Thanks!




--
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/