public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: scheduler / perf stat question about CPU-migrations
Date: Thu, 16 Jun 2011 17:03:51 +0200	[thread overview]
Message-ID: <20110616150347.GB23624@somewhere.redhat.com> (raw)
In-Reply-To: <E1QXDpy-0007Wr-5V@tytso-glaptop>

On Thu, Jun 16, 2011 at 10:46:26AM -0400, Theodore Ts'o wrote:
> Can someone tell me how I'm being confused?
> 
> I ran the following command as root:
> 
> 	perf stat schedtool -a 1 -e e2fsck -ft /dev/funarg/kbuild

A theory is that schedtool does:

if (!fork()) {
	set affinity there
	launch e2fsck
}

So schedtool as a parent doesn't change it's own affinity, which makes sense
as you only want to set it for the child.

By the time it is launched, do mmap, faults, etc... and after the wait()
finishes and it exits(). It has got many opportunities to migrate.

> 
> This runs e2fsck under perf, with the cpu affinity nailed to a single
> CPU.  I therefore expected the CPU-migrations field reported by perf to
> be 0.  That was not what I found, though:
> 
> Performance counter stats for 'schedtool -a 1 -e e2fsck -ft /dev/funarg/kbuild':
> 
>         1169.715766  task-clock-msecs         #      0.180 CPUs 
>                9212  context-switches         #      0.008 M/sec
>                 307  CPU-migrations           #      0.000 M/sec
>                1875  page-faults              #      0.002 M/sec
>          2737168498  cycles                   #   2340.029 M/sec
>          3125632038  instructions             #      1.142 IPC  
>           688556730  branches                 #    588.653 M/sec
>             7263580  branch-misses            #      1.055 %    
>            15222417  cache-references         #     13.014 M/sec
>             1488633  cache-misses             #      1.273 M/sec
> 
>         6.481483548  seconds time elapsed
> 
> How could this be?  The CPU-migrations event counter only gets
> incremented if a task changes CPU's, as seen in kernel/sched.c:
> 
> 	if (task_cpu(p) != new_cpu) {
> 		p->se.nr_migrations++;
> 		perf_sw_event(PERF_COUNT_SW_CPU_MIGRATIONS, 1, 1, NULL, 0);
> 	}
> 
> So it should be 0, not 307, right?    What am I missing?
> 
> 						- Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2011-06-16 15:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16 14:46 scheduler / perf stat question about CPU-migrations Theodore Ts'o
2011-06-16 15:03 ` Frederic Weisbecker [this message]
2011-06-16 15:11   ` Pádraig Brady
2011-06-16 15:18     ` Frederic Weisbecker
2011-06-17  2:44       ` Ted Ts'o
2011-06-17  5:58         ` David Ahern

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=20110616150347.GB23624@somewhere.redhat.com \
    --to=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.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