From: Arun Sharma <asharma@fb.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
avagin@gmail.com, linux-perf-users@vger.kernel.org,
acme@ghostprotocols.net, Stephane Eranian <eranian@google.com>
Subject: Re: Profiling sleep times?
Date: Sat, 22 Oct 2011 17:27:52 -0700 [thread overview]
Message-ID: <4EA35F88.9010803@fb.com> (raw)
In-Reply-To: <20111022104947.GB2811@somewhere.feld.cvut.cz>
On 10/22/11 3:49 AM, Frederic Weisbecker wrote:
> That's not only a problem of semantics although that alone is a problem,
> people will seldom read the documentation for corner cases, we should
> really stay consistant here: if remote callchains are really needed, we
> want a specific interface for that, not abusing the existing one that would
> only confuse people.
A separate interface sounds good.
>
> Now I still think doing remote callchains is asking for troubles: we need to
> ensure the target is really sleeping and is not going to be scheduled
> concurrently otherwise you might get weird or stale results. So the user needs
> to know which tracepoints are safe to perform this.
I expect this interface to be used in a small number of well known
places in the kernel.
[...]
>
> I think we should use something like a perf report plugin: perhaps something
> that can create a virtual event on top of real ones: compute the sched:sched_switch
> events, find the time tasks are sleeping and create virtual sleep events on top
> of that with a period weighted with the sleep time.
> Just a thought.
Right - whether we're doing wall-clock profiling or sleep profiling,
it'll involve looking at multiple real events.
I still see one problem with doing: perf record -ag -e <bunch of events>
and trying to sort through what happened. Unprivileged users who don't
have permissions to system wide profiling, but have privileges to
profile their own processes get locked out of this feature.
-Arun
prev parent reply other threads:[~2011-10-23 0:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-03 19:38 Profiling sleep times? Arun Sharma
2011-10-03 20:17 ` Peter Zijlstra
2011-10-03 21:53 ` Arun Sharma
2011-10-04 8:34 ` Peter Zijlstra
2011-10-06 21:56 ` Arun Sharma
2011-10-07 0:05 ` Arun Sharma
2011-10-07 1:30 ` Peter Zijlstra
2011-10-07 5:42 ` avagin
2011-10-07 9:33 ` Peter Zijlstra
2011-10-07 17:58 ` Arun Sharma
2011-10-07 23:16 ` avagin
2011-10-08 1:45 ` avagin
2011-10-10 18:50 ` Arun Sharma
2011-10-12 7:41 ` Ingo Molnar
2011-10-13 5:39 ` Andrew Vagin
2011-10-14 21:19 ` Arun Sharma
2011-10-15 17:00 ` Ingo Molnar
2011-10-15 19:22 ` Peter Zijlstra
2011-10-15 19:29 ` Peter Zijlstra
2011-10-18 1:07 ` Arun Sharma
2011-10-22 10:49 ` Frederic Weisbecker
2011-10-22 16:22 ` Andrew Wagin
2011-10-23 0:27 ` Arun Sharma [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EA35F88.9010803@fb.com \
--to=asharma@fb.com \
--cc=acme@ghostprotocols.net \
--cc=avagin@gmail.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).