From: Ingo Molnar on

* Frederic Weisbecker <fweisbec(a)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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on
On Thu, Jul 08, 2010 at 09:19:42AM +0200, Ingo Molnar wrote:
>
> * Frederic Weisbecker <fweisbec(a)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?



Yeah. In fact it would include too much by adding traces you don't need, so there
are more risks to lose traces while using perf sched record.




> > 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?



Yeah. In fact we need to add that from the tracing/scripting layer
and always check/report lost events to the user.



> > 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



Agreed. For now it's very tied to the cpu load idea, so the code needs to
be generalized to easily plug other sched drawing plugins. But yeah, that would
be indeed a good direction.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/