lkml.org 
[lkml]   [2007]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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.

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

    \
     
     \ /
      Last update: 2007-02-04 18:15    [W:0.026 / U:0.380 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site