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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux