Arnd Bergmann wrote:
On Tuesday 30 January 2007 23:54, Maynard Johnson wrote:
Why do you store them per spu in the first place? The physical spu
doesn't have any relevance to this at all, the only data that is
per spu is the sample data collected on a profiling interrupt,
which you can then copy in the per-context data on a context switch.
The sample data is written out to the event buffer on every profiling
interrupt. But we don't write out the SPU program counter samples
directly to the event buffer. First, we have to find the cached_info
for the appropriate SPU context to retrieve the cached vma-to-fileoffset
map. Then we do the vma_map_lookup to find the fileoffset corresponding
to the SPU PC sample, which we then write out to the event buffer. This
is one of the most time-critical pieces of the SPU profiling code, so I
used an array to hold the cached_info for fast random access. But as I
stated in a code comment above, the negative implication of this current
implementation is that the array can only hold the cached_info for
currently running SPU tasks. I need to give this some more thought.
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?
Please assume that in the near future we will be scheduling SPU contexts
in and out multiple times a second. Even in a single application, you
can easily have more contexts than you have physical SPUs.
Arnd, thanks for pointing this out. That's definitely a good reason why
my simplistic approach won't work. I'll look at other options.
The event buffer by definition needs to be per context. If you for some
Yes, and it is. Right now, with the current simplistic approach, the
context and the physical SPU are kept in sync.
reason want to collect the samples per physical SPU during an event
interrupt, you should at least make sure that they are copied into the
per-context event buffer on a context switch.
At the context switch point, you probably also want to drain the
hw event counters, so that you account all events correctly.
Yeah, that's a good idea. The few extraneous invalid samples would
probably never rise above the noise level, but we should do this anyway
for completeness.
We also want to be able to profile the context switch code itself, which
means that we also need one event buffer associated with the kernel to
collect events that for a zero context_id.
The hardware design precludes tracing both SPU and PPU simultaneously.
-Maynard
Of course, the recording of raw samples in the per-context buffer does
not need to have the dcookies along with it, you can still resolve
the pointers when the SPU context gets destroyed (or an object gets
unmapped).
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]
