[lkml]   [2007]   [Jan]   [30]   [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

    > I've given this some more thought, and I'm coming to the conclusion that
    > a pure array-based implementation for holding cached_info (getting rid
    > of the lists) would work well for the vast majority of cases in which
    > OProfile will be used. Yes, it is true that the mapping of an SPU
    > context to a phsyical spu-numbered array location cannot be guaranteed
    > to stay valid, and that's why I discard the cached_info at that array
    > location when the SPU task is switched out. Yes, it would be terribly
    > inefficient if the same SPU task gets switched back in later and we
    > would have to recreate the cached_info. However, I contend that
    > OProfile users are interested in profiling one application at a time.
    > They are not going to want to muddy the waters with multiple SPU apps
    > running at the same time. I can't think of any reason why someone would
    > conscisouly choose to do that.
    > Any thoughts from the general community, especially OProfile users?

    Well, it's my understanding that quite a few typical usage scenario
    involve different tasks running on different SPUs passing each other
    data around.


    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-01-31 00:37    [W:0.020 / U:69.976 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site