public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Vince Weaver <vweaver1@eecs.utk.edu>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Stephane Eranian <eranian@gmail.com>
Subject: Re: perf: is PERF_COUNT_SW_CONTEXT_SWITCHES a kernel or user event?
Date: Mon, 27 Jun 2011 20:59:36 +0200	[thread overview]
Message-ID: <20110627185933.GA3726@somewhere> (raw)
In-Reply-To: <1309171403.6701.77.camel@twins>

On Mon, Jun 27, 2011 at 12:43:23PM +0200, Peter Zijlstra wrote:
> On Fri, 2011-06-24 at 17:03 -0400, Vince Weaver wrote:
> > Hello
> > 
> > the commit included in 2.6.34:
> >   perf: Use hot regs with software sched switch/migrate events
> >   e49a5bd38159dfb1928fd25b173bc9de4bbadb21
> > 
> > Changes the behavior of the PERF_COUNT_SW_CONTEXT_SWITCHES
> > counter.
> > 
> > Before 2.6.34 all of the PERF_COUNT_SW_CONTEXT_SWITCHES events were 
> > counted as happening in userspace (they show up in "perf stat -e cs:u") 
> > but after the commit they always happen in kernelspace ("perf stat -e 
> > cs:k").
> > 
> > Was this intended behavior?
> > I'm writing a validation test for this and want to make sure I get it
> > right.
> > 
> > This can be confusing if your tool defaults to userspace only counts (PAPI 
> > does this).
> 
> hurm, difficult case, like the changelog explains the previous behaviour
> wasn't ideal either. Seems like we want somewhat of a middle ground
> there, but I'm not quite sure how to make that happen.
> 
> Let me ponder things for a bit.

If you consider the strict meaning of exclude_user/exclude_kernel, they exclude
events that _happen_ in user/kernel space. And context switches happen in kernel
space.

Using the resuming ip in userspace if exclude_kernel and the current kernel
ip if exclude_user or default no exclude is a pure arbitrary interpretation of the
exclude things. We could, but I believe it only makes the things confusing for people.

If some users want an option where the event can trigger everywhere but hists are
sorted by the resuming userspace ip, let's tweak the "perf report -s parent" thing
to take the resuming userspace ip from the callchain as the parent and you get
the desired result.

This will have the advantage to keep exclude_* behaviour consistent everywhere and
if we want to have that user resuming ip feature, it will be available for any kind of
events.

  reply	other threads:[~2011-06-27 19:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-24 21:03 perf: is PERF_COUNT_SW_CONTEXT_SWITCHES a kernel or user event? Vince Weaver
2011-06-27 10:43 ` Peter Zijlstra
2011-06-27 18:59   ` Frederic Weisbecker [this message]
2011-06-28 17:30     ` Vince Weaver

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=20110627185933.GA3726@somewhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=eranian@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=vweaver1@eecs.utk.edu \
    /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