All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Arun Sharma <asharma@fb.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 03:27:35 +0100	[thread overview]
Message-ID: <20120126022732.GH20878@somewhere> (raw)
In-Reply-To: <4F20823A.6010808@fb.com>

On Wed, Jan 25, 2012 at 02:29:14PM -0800, Arun Sharma wrote:
> On 1/25/12 12:15 PM, Steven Rostedt wrote:
> 
> >trace-cmd record -e sched_switch -f 'prev_state == 1 || prev_state == 2' -e sched_stat_sleep sleep 3
> >
> >I'm not sure the filter is even needed, and it should still keep up
> >fine.
> 
> Better - I didn't see any overruns with trace-cmd.
> 
> 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?

> 
> There is consensus here that touching an extra cacheline in the
> context switch path is a good trade-off given the usefulness of
> sleep profiling in troubleshooting latency problems.
> 
> Since it may not be a good trade-off for everyone, we just need to
> figure out where to store some per-task state. To recap two
> potential paths to investigate:
> 
> * store sleep_start someplace else that no one other than
> sched_stat_sleeptime() knows about.
> 
> * store state in task struct that remembers whether the last context
> switch was a preemption or not.
> 
>  -Arun

  reply	other threads:[~2012-01-26  2:27 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 [this message]
2012-01-26 19:13                       ` Arun Sharma
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=20120126022732.GH20878@somewhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=asharma@fb.com \
    --cc=avagin@openvz.org \
    --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.