Re: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile for profiling Cell BE SPUs -- update

[Maynard Johnson <maynardj@us.ibm.com>]

Arnd Bergmann wrote:

> On Saturday 03 February 2007 21:03, Maynard Johnson wrote:
>  
>
> > I presume you mean 'object_id'. 
> >    
>
> Right, sorry for the confusion.
>
>  
>
> > What you're asking for is a new  
> > requirement, and one which I don't believe is achievable in the current 
> > timeframe.  Since this is spufs code that's dynamicaly loaded into the 
> > SPU at runtime, the symbol information for this code is not accessible 
> > to the userspace post-processing tools.
> >    
>
> We can always fix the user space tool later, but it is important to
> get at least the kernel interface right, so we can add the functionality
> later without breaking new user space on old kernels or vice versa.
>  
There's no obvious solution to this problem, so it's going to take some 
design effort to come up with a solution.  We can work on the problem, 
but I don't think we can allow it to get in the way of getting our 
currently proposed SPU profiling functionality into the kernel.

>  
>
> > It would require an altogether  
> > different mechanism to record samples along with necessary information, 
> > not to mention the changes required in the post-processing tools.  This 
> > will have to be a future enhancement.
> >    
>
> So what do you do with the samples for object_id == 0? I would expect them
> to be simply added to the sample buffer for the kernel, which is sort
> of special in oprofile anyway.
>  
There is no sample buffer for the kernel in SPU profiling.  When 
OProfile gets notified of an SPU task switching out (object_if == 0), we 
stop recording samples for the corresponding SPU.  If SPUFs sends the 
notification after the spu_save operation, we still would be collecting 
samples during that time; however, since the VMAs of these samples would 
not map to any fileoffset in the SPU binary that's executing, our 
current implementation throws them away.  We could change that behavior 
and record them in the samples buffer as "anonymous samples".  Not sure 
it that would help too much, as you wouldn't be able to distinguish 
between spu_save samples and samples from generated stubs that are 
executing from the stack.

-Maynard

> 	Arnd <><
>  


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