Re: [perfmon2] comments on Performance Counters for Linux (PCL)

[stephane eranian <eranian@googlemail.com>]

Hi,

On Fri, May 29, 2009 at 1:24 AM, Paul Mackerras <paulus@samba.org> wrote:
> Ingo Molnar writes:
>
>> * Corey Ashford <cjashfor@linux.vnet.ibm.com> wrote:
>> >> So you're suggesting to artificually strech periods by say
>> >> composing a single overflow from smaller ones, ignoring the
>> >> intermediate overflow events?
>> >>
>> >> That sounds doable, again, patch welcome.
>> >
>> > I definitely agree with Stephane's point on this one.  I had
>> > assumed that long irq_periods (longer than the width of the
>> > counter) would be synthesized as you suggest.  If this is not the
>> > case, PCL should be changed so that it does, -or- at a minimum,
>> > the user should get an error back stating that the period is too
>> > long for the hardware counter.
>>
>> this looks somewhat academic - at least on x86, even the fastest
>> events (say cycles) with a 32 bit overflow means one event per
>> second on 4GB. That's not a significant event count in practice.
>> What's the minimum width we are talking about on Power?
>
> 32 bits, but since the top bit is effectively a level-sensitive
> interrupt request, the maximum period in hardware is 2^31 counts.
>
This is exactly the same on Intel X86: 31 bits.
AMD is different.

Unfortunately, the Intel document is very obscure about this restriction.

Let's take Core. 40-bit wide counters. If you read with RDPMC
you get 40-bit worth of data, same with RDMSR.

If you write with WRMSR, you can only modify the bottom 32
bits. But bit 31 is the sign bit. Bit 32-39 are sign extension
of bit 31.

To trigger an overflow, bit 31 must be set, i.e., interrupt is triggered
when 40 bits transition back to 0.

Therefore your actual degree of freedom for the sampling period
is 31 bits.