All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.