Re: re-enable Nehalem raw Offcore-Events support

[Corey Ashford <cjashfor@linux.vnet.ibm.com>]

On 04/29/2011 10:42 AM, Thomas Gleixner wrote:
> On Fri, 29 Apr 2011, Andi Kleen wrote:
>
>>>>   2.  Users are too stupid to use the raw functionality properly;
>>>>       we should only allow a kernel-developer-approved small subset
>>>>       of the features provided by the CPU as described in the intel
>>>>       developers manuals.
>>>>
>>>> #2 seems like a gross misinterpretation of the whole "Linux gives you
>>>> enough rope to shoot yourself in the foot" policy from days passed, but
>>>> maybe things have moved on.
>>>
>>> That's a gross misrepresentation of what Ingo has been saying on LKML.
>>> Really, learn to work with relevant maintainers before you ask Linus
>>> to revert something.
>>
>> Ingo may not have explicitely said (2), but at least his revert (disabling
>> the raw interface users are asking for) is practically implementing (2).
>>
>> Actions speak louder than words.
>>
>> That is either you have a raw interface or you only have the cooked
>> interface or you have both. Since he reverted raw only cooked
>> is left, which is (2)
>>
>> I agree with Vince it's a bad policy.
>
> No, it's not the raw interface will be made available when the proper
> set of abstracted functionality has been added and settled down,
> simply because it might to change the way the raw event is exposed. As
> long there are open questions which might have an influence on the
> exposure of the raw event, it's completely correct to keep it
> disabled.

Carl Love and I recently completed some work to add perf_events support 
for the IBM Blue Waters machine's "CPU networking" chip, called the 
Torrent chip.  We did all of this work based on a RHEL 6 kernel 
(2.6.32ish), which doesn't have Peter's more recent multi-PMU support.

I would say that most if not all of the events are not generalizable in 
the sense that you are talking about; the events are very specific to 
the Torrent chip.  For example, the Torrent chip communicates with four 
POWER7 chips via a high-speed serial interconnect, called the W, X, Y, 
and Z links, and it also has similar links which connect to other 
Torrent chips, and to other nodes.  The events measure certain types of 
activity on these various links, for example "X link receive idle".

So if I'm understanding what you have said correctly, we would not be 
able to get a forward port of this code committed without abstracting 
these events in a away that's acceptable to the kernel community.  Is 
that right?  If so, this is important for us to know so that we can 
correctly size the work effort involved in the forward port.

Thanks for your consideration,

- Corey