On Tue, Sep 27, 2011 at 04:05:51PM +0200, Peter Zijlstra wrote:Thank you for comments and suggestions. I take timeout to think over them.On Mon, 2011-09-26 at 19:55 +0400, Andrew Vagin wrote:There is also a problem in perf tools because we are dealing with aKnow issues:Also, it changes the semantics of tracepoint, normally you return the
* Now call chains for non-current tasks are collected on x86 only,
but it may be done for other architectures simply.
* It collects only kernel call chains, because we can't get direct
access to memory of other processes and this operation should be
fast enough.
callchain leading to the tracepoint, this changes that.
I'm not entirely against it, as I can see the use, but I would like to
solicit other opinions.
callchain that doesn't belong to the current thread memory mapping and symbol
space. I believe that's a problem once we deal with the userspace part of
the callchain.
That and the fact there are other ways to get that callchain like taking
the one of the last sched_switch event from the waked thread.
Perhaps we should use the sched_switch event and a post_sched_switch
event, compute the time difference as a weight and use the callchain of any of
those. Perhaps as a plugin in perf report?
In any case that rather sounds like something that should be done in post-processing
in userspace, in perf tools.
We should probably avoid the remote callchains, sounds like asking for complications
everywhere.