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

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Arnd Bergmann <arnd@...>
Cc: <cbe-oss-dev@...>, <linux-kernel@...>, <linuxppc-dev@...>, <oprofile-list@...>, Anton Blanchard <anton@...>
Date: Tuesday, January 30, 2007 - 5:41 pm

Arnd Bergmann wrote:

Anton (added to cc list) may be another good reviewer of 
drivers/oprofile changes.
OK.
Sure.
[snip]
OK, we'll add 'spu_prof' prefix to them.
[snip]
Will do.
fixed
Yes, good suggestion.
According to Tom Gleixner, "hrtimer_forward is a convenience function to 
move the expiry time of a timer forward in multiples of the interval, so 
it is in the future.  After setting the expiry time you restart the 
timer either with [sic] a return HRTIMER_RESTART (if you are in the 
timer callback function)."
OK
Since OProfile is a statistical profiler, the exact frequency is not 
critical.  The user is going to be looking for hot spots in their code, 
so it's all relative.  With that said,  I don't imagine using the 
cpufreq notiication would be a big deal.  We'll look at it.
OK, I'll check it out.
OK.
No, you're right.  :-)
OK
info_list is an array of n lists, where n is the number of SPUs.
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.
OK
OK
uh-huh
For embedded SPU app, the post-processing tool opens the PPE binary app 
file and obtains the SPU ELF embedded thereine, and from that, we obtain 
the name of the SPU binary.  Also, the app name is included in the 
report, along with the SPU binary filename, if the report contains 
samples from more than one application.
OK, we'll fix up.
Our userspace tool ensures the cpufreq module is loaded.
Me neither.  Carl, can you comment?
It is the only file-scoped variable relating to SPU profiling, and will 
always be non-zero when the user selects to perform SPU profiling. 
Seemed like a logical-enough choice to me.
The hardware setup is so completely different, I don't think there's a 
viable way of switching between PPU profiling and SPU profiling without 
a "stop" in between.


-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile f..., Maynard Johnson, (Tue Jan 30, 5:41 pm)
Re: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile f..., Benjamin Herrenschmidt, (Tue Jan 30, 7:34 pm)