Re: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile for profiling Cell BE SPUs -- update
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2007-01-30 23:34:32
Also in:
lkml
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2007-01-30 23:34:32
Also in:
lkml
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. Ben.