Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linuxtools-dev] Oprofile plugin issues with Power processors

Severin Gehwolf wrote:
> On Fri, 2011-02-25 at 15:49 -0300, Daniel HB wrote:
>> I'm currently trying to make the Oprofile plugin work on a Power6
>> machine. I've come to this mailing list a couple weeks ago with a
>> complaint that generated a bug
>> ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=336977 ) which we
>> managed to solve - the XML error was a bogus character generated on the
>> oprofile application for Power.
>>
>> That wasn't enough to make the plugin work. On some point of its
>> initialization, the plugin queries 'ophelp <event_name>' searching for
>> index values to each event detected. It turns out that, on x86, these
>> events are valid integer values, and the plugin was built around that
>> assumption. However, on Power, they aren't always a valid integer.
>> Several 'ophelp <event_name>' calls on Power returns several hex values,
>> firing an exception on the plugin since an integer value was expected.
>>
>> Speaking with Maynard Johnson, lead maintainer of Oprofile, we agreed
>> that the plugin shouldn't be using any value obtained by 'ophelp
>> <event_name>' since it's a non-architected interface. In other words,
>> the GUI shouldn't be issuing this command neither using its return
>> value.
> 
> I see. The obvious follow-up question is what does Maynard suggest to
> use instead?
I personally haven't had time to look at the oprofile plugin code, so I don't how it might be using the returned value 'ophelp <event_name>'.  But I can tell you that the purpose of this particular incantation of ophelp is for opcontrol (oprofile's control script) to obtain the event encoding which is passed to the oprofile kernel driver via the oprofilefs pseudo filesystem.  The kernel driver uses that information to program the performance monitor unit hardware. On Intel, this event encoding is a simple integer value; on Power systems, the encoding is done via several register values.  The opcontrol script has code that can detect when the returned value is more than a simple integer, and it handles that extra data.

So IMHO, I can't see any valid purpose in using that ophelp call from within the GUI.  ophelp has an '--xml' option which should provide GUI tools with all the information they need about events in an architected manner -- guaranteed to work on any hardware arch.  If there is something missing in the XML output that a GUI tool *really* needs, we'll gladly address it.

Thanks.
-Maynard
> 
>> Since it's quite a change on the code (I took a look at where the output
>> of ophelp is used and there are a lot of places), I think I would need
>> some help doing that.
> 
> Ok, I'd be happy to work with you on that. We should aim for a solution
> which will work on x86 and Power (both 32 and 64 bit, at least). Ideally
> there is some architected interface we could use.
> 
>> Any thoughts/advice?
> 
> Could you please open an Eclipse.org bug so that we can hash out details
> there? Please CC me to that bug you open (sgehwolf@xxxxxxxxxx) and we
> continue our discussion there.
> 
> Thanks!
> 
> --Severin
> 
>> - daniel
>>
>> _______________________________________________
>> linuxtools-dev mailing list
>> linuxtools-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
> 
> 
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev



Back to the top