[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EE01ACB.1000102@fb.com>
Date: Wed, 7 Dec 2011 18:02:51 -0800
From: Arun Sharma <asharma@...com>
To: Frederic Weisbecker <fweisbec@...il.com>
CC: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Vagin <avagin@...nvz.org>,
<linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Paul Mackerras <paulus@...ba.org>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: Re: [PATCH 3/4] trace: add ability to collect call chain of non-current
task.
On 7/22/64 12:06 PM, Frederic Weisbecker wrote:
[..]
>
> 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.
Agreed on remote callchains and maintaining consistency about what the
tracepoints mean.
As I said on the other thread, post-processing in userspace has the
issue that we collect more info than we actually need and under load,
perf record can't keep up.
Attached is an alternative approach that does what you allude to above.
perf record -agPe sched:sched_switch --filter "delay > 1000000" -- sleep 1
allows us to collect a lot less. For some reason, "perf script" shows
the correct delay field, but the sample period still contains 1 (i.e
__perf_count() hint is not working for me).
-Arun
View attachment "sched-switch-delay.patch" of type "text/plain" (4651 bytes)
Powered by blists - more mailing lists