Vince,
I don't know much about the Niagara PMU. I am just making sure the code still
compiles.
However here are a few comments:
- typically for 32-bit counters, it means bit 31 is the sign bit. so
the actual width is 31, i.e.,
bits you can set anyway you want. This is the way this is handled
on x86, for instance
- what matter is how you need to set bits 31-64 to trigger the
overflow. This determines
the overflow detection test.
- as Corey points out, you don't want to test against 0 if the PMU
does not freeze instantly on overflow.
Depending on the measured event, you may see some before you reach
the PMU interrupt handler
which is going to first stop all counters. You typically test the
sign extension bit.
- the interrupt handler does not simply add 2^31, it does add 1 +
2^31, if I recall
On Fri, Aug 15, 2008 at 7:30 PM, Vince Weaver <[EMAIL PROTECTED]> wrote:
> Hello
>
> When doing some experiments on a SPARC niagara1 machine, I noticed that for
> large runs the INSTR_CNT count was off by a factor of two.
>
> For example, I have a microbenchmark that runs a 4-instruction loop a given
> number of times (code attached). The results are as follows
>
> ! g2 = 1,000 result = 4,005 (correct)
> ! g2 = 10,000 result = 40,006 (correct)
> ! g2 = 100,000 result = 400,006 (correct)
> ! g2 = 1,000,000 result = 4,000,006 (correct)
> ! g2 = 10,000,000 result = 40,000,006 (correct)
> ! g2 = 100,000,000 result = 400,000,006 (correct)
> ! g2 = 1,000,000,000 result = 4,000,000,006 (correct)
>
> ! g2 = 2,000,000,000 result = 5,852,516,357 (incorrect)
> ! = 0x1 5cd6 5005
> ! should be = 0x1 dcd6 5005
>
>
>> From looking at the SPARC/T1 (niagara) documentation I see that the PIC
>
> (counter) register overflows at 32-bits, but in the perfmon code we have
> counter_width set to 31. Thus when the counter overflows, we only add
> 2^31 to the emulated 64-bit counter instead of the proper 2^32.
>
> I tried changing counter_width to 32 in arch/sparc64/perfmon/perfmon.c
> but this doesn't fix things. In __pfm_get_ovfl_pmds() we detect if
> an overflow has occurred by anding against 1ULL<<counter_width, but since
> the PIC register is only 32-bits, this will never be true.
>
> So, is there a proper way to fix this? I'm not sure how other architectures
> handle cases like this.
>
> Thanks,
>
> Vince
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
