From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Wed, 10 Dec 2008 12:52:45 -0500
Subject: [ltt-dev] [patch] add tracepoints to trace
	activate/deactivate	task
In-Reply-To: <20081210171423.GA3137@redhat.com>
References: <20081208194948.GC27166@redhat.com> <1228766050.6939.7.camel@twins>
	<20081208223840.GA30314@redhat.com>
	<1228776169.12729.2.camel@twins> <20081209210048.GA4440@redhat.com>
	<20081209221012.GA4673@Krystal> <1228892902.6978.23.camel@twins>
	<20081210122712.GC28524@Krystal> <1228914941.12143.12.camel@twins>
	<20081210171423.GA3137@redhat.com>
Message-ID: <20081210175245.GA13055@Krystal>

* Jason Baron (jbaron at redhat.com) wrote:
> On Wed, Dec 10, 2008 at 02:15:41PM +0100, Peter Zijlstra wrote:
> > On Wed, 2008-12-10 at 07:27 -0500, Mathieu Desnoyers wrote:
> > > 
> > > Do you think there would be other events that Jason would need to
> > > identify every time a task gets de/activated, or he is able to
> > > reconstruct this from the current tracepoints ?
> > 
> > I don't know what events Jason wants, some of the things he mentioned
> > map directly to syscalls, so I'm not sure if we'd want to catch it at a
> > generic syscall layer, or a tracepoint per syscall guts.
> > 
> > 
> 
> My goal is to instrument the scheduler at the most "interesting" points.
> Activate and Deactivate allow me to directly figure out queue length (posted in
> my previous mail), how long a process wait on a queue, and when a
> process moves between queues. Yes, I might be able to figure these out
> from insturmentation calls from schedule(), try_to_wake_up(),
> wake_up_new_task(), pull_task(), migrate_task(), etc. But its going to
> be awfully complex. Activate/deactivate task seem like very core basic
> scheduler primitives.
> 
> Adding a tracepoint to set_task_cpu() is good but it doesn't tell me
> about whether or not a task is on queue. It simply tells me when a task
> is assigned a different cpu (which activate/deactivate can do as well).
> 
> I understand and appreciate what you guys are saying about do not
> instrument the code too generally, but IMHO activate/deactivate are core
> scheduler primitives, which are difficult to piece together otherwise. I
> can up with more scripts that show their utility.
> 

Would it be possible to simply use

p->se.on_rq

in the events already instrumenting the scheduler to keep track of the
activation state and manage to get the same result ?

And also, adding duplicate instrumentation to simplify tracer analysis
is imho the wrong approach.

Mathieu


> 
> thanks,
> 
> -Jason 
> 
> 
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68