[Cbe-oss-dev] [PATCH 2/8] spufs: Trace spufs_stop_callback events

[Julio M. Merino Vidal]

On Wed, Apr 30, 2008 at 04:46:42PM +1000, Jeremy Kerr wrote:
> Hi Julio,
> 
> > I am using the stop callback marker to quantify the time it takes
> > from the reception of the SPU's stop interrupt to the wake up (well,
> > start of execution) of its corresponding PPU control thread.  I'm not
> > doing this with sputrace because of the problem I mentioned in the
> > code; but with SystemTap I can hook to that marker just fine, and log
> > a trace entry easily.
> 
> Is this something that needs to be in mainline though, if you've already 
> done the instrumentation?

Doesn't *need* to be in mainline, but I'd like it to be there.  The same
reason could be given for any of the other markers, to not add them to the
tree.  If sputrace is not using this specific marker is because of
limitations of its code, not because the marker is not useful.  And...
As was mentioned when sputrace was introduced, or what I understood, is that
sputrace is just a hack: should the kernel grow custom *trace modules for
every subsystem?  No; there are frameworks out there to do that in a nicer
way (lttng, systemtap).  If/when these frameworks are mature enough, I
expect sputrace to disappear.  But still, in that case, the markers will
have to be in the code.

Also, I have a cbe.stp tapset for SystemTap (i.e. a set of rules to
easily hook into spufs' markers) that I'd like to submit to its authors
once all these markers get applied to the tree.  This will allow very simple
and powerful tracing of spufs with minimum hassle, assuming all the markers
get into the tree; if the user has to apply patches manually, things are
not as smooth as they'd be.

> Since we're close to the end of the .26 merge window, I've applied a 
> subset of your patches for .26, as we need to get the .26 patches 
> upstream today. We can discuss the rest for inclusion in a later 
> release.

OK, thanks.  If you are not going to apply everything today, you can also
delay this one as well.

Cheers,

-- 
Julio M. Merino Vidal <jmerino at ac.upc.edu>