[Cbe-oss-dev] Refactored cell powerpc oprofile patch

Barrow, Denis Denis.Barrow at eu.sony.com
Tue Mar 4 22:12:23 EST 2008


Hi Guys,
This is a politically incorrect letter sorry I'm not trying to flame anyone.
Firstly I don't like the size of the patch any more than you do.
It was a case of "oh dear god" is it that big. I absolutely hate
it & I don't know how to make it better.
This is my first job since I came to Sony and
I genuinely don't feel I've done anything useful yet.

I was basically asked by Geoff to put common code in op_model_cell.c
& architecture dependent code in pmu.c for the cell
& the ps3 code in ps3-lpm.c I did this fairly blindly
I don't have any appreciation of the profiling hardware on the
cell yet. I don't know how to make it a smaller patch
aside from seperating out Geoff's patch again.

Moving the archecture dependent code into pmu.c meant that the
pmu.c was now trying to link into the oprofile module i.e. the
kernel was trying to call functions in the oprofile module...
causing link errors this forced me to make pmu.c part of the oprofile
module resulting in a few thousand lines of code changes.

The callbacks to oprof.c are needed because if the ps3-lpm.c
driver is rmmoded it leaves a heap of null pointers  
in pmu_ops I would have to check for null pointers all over
op_model_cell.c I could make op_model_cell much bigger if you don't
like this with a heap of checks for null pointers all over the place.
with the pmu_ops in op_model_cell.c

When ps3-lpm.c is insmodded it needs to restart the call the generic
code to restart oprofile as some stuff in the generic code may need to
be reinitialised i.e. model = op_powerpc_model;
I might be able to get away without this re registering but this
might change in future & just call oprofile_arch_init but
I don't know if this will create side effects in oprof.c.

As an aside does anybody actually like the profiling hardware
on the cell processor to me it looks like a waste of silicon.
With its 128 bit wide bus.
It looks very complicated to do so little & I don't fully
appreciate how you actually program the thing yet.
e.g. it traces TLB & cache misses without actually telling
you where they are happening. 

Intel have a very useful feature of tracing branches in the
code i.e. it can do profiling without modifing the binaries.

An accurate software simulator of the processor could tell
you heaps more information where cache misses & tlb misses
are occuring & profiling the code could be done also.

If somebody actually likes the profiling hardware on
the cell I'd like a chat to learn how to appreciate it.

With kind regards,
 
Denis Barrow
Software Engineer

Sony Network and Software Technology Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:	+32 (0)2 700 8611	
Fax:	+32 (0)2 700 8622	
E-mail:	Denis.Barrow at eu.sony.com	
Internet:	www.sony-europe.com	
 	

************************************************************************
The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s).  Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender.  The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies.  Sony email is for business use only.

This email and any response may be monitored by Sony to be in compliance with Sony’s global policies and standards


More information about the cbe-oss-dev mailing list