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

Denis Joseph Barrow denis.barrow at sonycom.com
Thu Mar 6 21:04:07 EST 2008


Hi Carl,
You know more about the ps3-lpm module than I do, I didn't write it.
you have a much better grasp of the performance monitor registers

With the rearrangement of code discussed in our irc meeting with Geoff
& Geert. The oprofile module will now be dependant on in the lpm
module symbol ps3_lpm_open AFAIR when Geert & I walked
the code. This means that oprofile needs to be rmmodded before
the oprofile module can be rmmodded.
We should no longer have the issue of the lpm modules pmu ops pointing
at a module functions that were in ps3-lpm which are no longer loaded 
anymore.

I don't think I can explain the reregister problem with my previous 
patch that
existed in any simpler terms than I already did. The design was
bad anyway you'd have learned nothing useful from it & with the new patch
the problem should no longer exist.


Carl Love wrote:
> Denis:
>
> Can you give an overview of what the ps3-lpm module does?  What happens
> when ps3-lpm.c is remmodded?  I guess I need to understand what the
> module does so I can figure out what impact it has on OProfile.  I
> understand the processor architecture but I am not at all familiar with
> the PS3 system as a whole.
>
>            Carl Love
>
>
>
> On Wed, 2008-03-05 at 10:57 +0100, Denis Joseph Barrow wrote:
>   
>>> You made the comment  "When ps3-lpm.c is insmodded it needs to restart 
>>>       
>> the call the >generic code to restart oprofile as some stuff".  I don't 
>> follow this.
>>
>> The ps3-lpm.ko driver can be inserted & removed in spite of oprofile
>> actually using it. i.e. if ps3-lpm.ko is remmodded while oprofile
>> is using it oprofile must be stopped as the pmu_ops now point to 
>> functions which were in ps3-lpm.ko & will crash the kernel.
>> I was thinking about this yesterday & it probably would be nicer to
>> have a set of pmu_ops which point to functions which do nothing.
>> This however makes the patch bigger as I'd have 20 or 30 functions
>> for the pmu_ops which actually do nothing.
>>
>> oprofile has no dependancies on ps3-lpm.ko.
>> This means that I need to reregister ps3-lpm.ko with oprofile if it
>> is inserted late. It is however inserted by default by udev
>> but it can be rmmoded as so symbol in oprofile depends on it being
>> loaded.
>>
>> If ps3-lpm.ko is always around I don't see any advantage in making
>> it a module except that it will only be loaded if the kernel
>> is actually running on a ps3.
>> If the module is always loaded before oprofile which it is at the moment
>> & is gauranteed  to stay loaded I can remove my re registeration rubbish 
>> ( probably
>> around 200 lines of bad code).
>> Will I force the module ps3-lpm.ko use count to 1 if it is a ps3 & is 
>> probed Geoff ?
>> so it can't be unloaded if oprofile is put running?
>> How do I detect if oprofile is running?
>>
>>     
>
> _______________________________________________
> cbe-oss-dev mailing list
> cbe-oss-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/cbe-oss-dev
>
>   


-- 
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 sonycom.com
Internet:	www.sony-europe.com	




More information about the cbe-oss-dev mailing list