[PATCH] perf_event: e500 support

Kumar Gala galak at kernel.crashing.org
Thu Feb 18 14:33:06 EST 2010


On Feb 11, 2010, at 10:56 AM, Scott Wood wrote:

> Paul Mackerras wrote:
>> On Wed, Feb 10, 2010 at 06:06:10PM -0600, Scott Wood wrote:
>>> Paul Mackerras wrote:
>>>>> Some limitations:
>>>>> - No threshold support -- need to figure out how to represent it in
>>>>> the event struct from userspace.
>>>> What does "threshold support" mean in this context?  Does it mean
>>>> something different from getting an interrupt after N events have been
>>>> counted?  Or does it mean counting instances where something takes
>>>> longer than a specific number of cycles?
>>> The latter.
>> OK.  I handled that on classic by using some extra high bits in the
>> event config for the threshold value. 
> 
> OK.
> 
>> If you have a single threshold
>> value in hardware but more than one event that uses that threshold
>> value, then you will need to add a constraint that all threshold
>> events have to specify the same threshold.
> 
> There's a separate threshold for each counter.
> 
>> So, it sounds like you have a class of events which are the
>> thresholding events, and two constraints:
>> * at most two events in the thresholding event class
>> * at most four events in total
>> Are there other constraints?  Apart from the thresholding events, can
>> any event go on any counter, or can some events only be counted on one
>> particular counter?
> 
> No, those are the only constraints.
> 
>> If your constraints are just the two listed above (<= 2 threshold
>> events, <= 4 events total), then doing it the obvious straightforward
>> way is fine.  If there are other constraints as well, such as certain
>> events only being available on one specific PMC, then you should
>> consider reusing the constraint checking machinery from ppc64.
> 
> I'll stick with the straightforward approach then.  If future chips have more complicated constraints we can revisit using the more general scheme.

Paul,

Other than splitting the patch did you have any other changes you wanted to see before we'd get an Ack.  I'd like to see this go in for .34.

- k


More information about the Linuxppc-dev mailing list