All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Li Zefan <lizf@cn.fujitsu.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tom Zanussi <tzanussi@gmail.com>, Mike Galbraith <efault@gmx.de>,
	Venkatesh Pallipadi <venki@google.com>,
	Pierre Tardy <tardyp@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] perf migration
Date: Thu, 8 Jul 2010 09:19:42 +0200	[thread overview]
Message-ID: <20100708071942.GA26454@elte.hu> (raw)
In-Reply-To: <20100707151318.GA5984@nowhere>


* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> Hi,
> 
> To begin with, the name is a bit pompous. It's not a strong cpu task 
> migration observer as it's only based on the number of tasks living in a cpu 
> runqueue. This is the only basis for the cpu load: it doesn't handle the 
> nice level, scheduler classes, of each tasks (except idle ones that don't 
> count on the load).
> 
> At least not yet.
> 
> But still I think it's a cool toy, I've been playing with it for the last 
> weeks and it can give you a nice overview of what happens wrt migration 
> decisions for each migration opportunities: wake up, fork and exec, sleep 
> (sleep doesn't involve migration decision, but it's still an rq detach), and 
> load balancing. In fact it's more about "runqueue events".

Cool, looks really nice!

> == How to use ==
> 
> 
> I suggest you to use latest tip:/perf/core
> 
> Run the following command (followed by a command if you want):
> 
> $ sudo ./perf record -m 16384 -a -e sched:sched_wakeup -e sched:sched_wakeup_new -e sched:sched_switch -e sched:sched_migrate_task

Does 'perf sched record' include these events?

> Now ensure you have no lost events:
> 
> 
> $ sudo ./perf trace -d
> Misordered timestamps: 0
> Lost events: 0 <----

We need some warning for this in the GUI i guess?

> If so you need to increase the buffer size (-m nr_pages option in perf record).
> 
> Then put the script in the tools/perf directory and run it:
> 
> $ ./perf trace -s migration.py
> 
> You'll need wxpython.

Looks like this could be turned into 'perf sched view' or 'perf sched 
migration'?

How tasks schedule/migrate is basically how scheduler developers look at 
sched-trace data, so it would be nice if your GUI became the gui for perf 
sched.

	Ingo

  reply	other threads:[~2010-07-08  7:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07 15:13 [RFC] perf migration Frederic Weisbecker
2010-07-08  7:19 ` Ingo Molnar [this message]
2010-07-20 14:59   ` Frederic Weisbecker

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=20100708071942.GA26454@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=efault@gmx.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=rostedt@goodmis.org \
    --cc=tardyp@gmail.com \
    --cc=tzanussi@gmail.com \
    --cc=venki@google.com \
    /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.