[lkml]   [2007]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile for profiling Cell BE SPUs -- update
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.


> Arnd <><

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-04 18:15    [W:0.071 / U:0.812 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site