From: Arun Sharma <asharma@fb.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
<linux-kernel@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Andrew Vagin <avagin@openvz.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] trace: reset sleep/block start time on task switch
Date: Thu, 26 Jan 2012 11:13:42 -0800 [thread overview]
Message-ID: <4F21A5E6.9030305@fb.com> (raw)
In-Reply-To: <20120126022732.GH20878@somewhere>
On 1/25/12 6:27 PM, Frederic Weisbecker wrote:
>> Even if we resolve the sampling rate related problems, there is the
>> issue of: can we trust that a sampled sched_switch event and a
>> sampled sched_stat_sleep event actually match each other?
>
> Well, a sched_stat_sleep event should match the sched_switch with
> prev as the last targeted task.
>
> Or am I missing something?
I was thinking about large systems with 100k+ sched_switch events, where
the user wants to just sample 1k events/sec.
perf record -F 1000 -e sched:sched_switch -a -- sleep 1
Doesn't look like we're using sampling for tracepoint events? The rest
of this makes sense only if we're sampling tracepoint events (eg: to
limit the impact on the system being profiled/traced).
On a system with 50k sched_switch and 10k sched_stat_sleep events, if we
sample at 1000 events/sec, we may lose an event of interest either due
to finite buffer sizes or to sampling, which is why a single event based
sleep profiling is of interest to us.
On 1/25/12 6:21 PM, Frederic Weisbecker wrote:
>
> Have you tried to tweak the -m options to increase the size of the
buffer?
-m4:
Processed 276875 events and lost 4772 chunks!
Check IO/CPU overload!
-m5:
Fatal: failed to mmap with 22 (Invalid argument)
-Arun
next prev parent reply other threads:[~2012-01-26 19:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-20 2:20 [PATCH] trace: reset sleep/block start time on task switch Arun Sharma
2012-01-23 11:34 ` Peter Zijlstra
2012-01-23 18:41 ` Arun Sharma
2012-01-23 21:03 ` Peter Zijlstra
2012-01-23 23:02 ` Arun Sharma
2012-01-24 14:27 ` Peter Zijlstra
2012-01-24 21:46 ` Arun Sharma
2012-01-25 9:20 ` Frederic Weisbecker
2012-01-25 19:50 ` Arun Sharma
2012-01-25 20:15 ` Steven Rostedt
2012-01-25 22:29 ` Arun Sharma
2012-01-26 2:27 ` Frederic Weisbecker
2012-01-26 19:13 ` Arun Sharma [this message]
2012-01-26 2:21 ` Frederic Weisbecker
2012-02-10 18:43 ` Peter Zijlstra
2012-02-10 20:07 ` Arun Sharma
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=4F21A5E6.9030305@fb.com \
--to=asharma@fb.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=avagin@openvz.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.