Prev: [GIT PULL] regulator fix
Next: [PATCH v2 -stable 2.6.32.7] clocksource: fix compilation if no GENERIC_TIME
From: Stephane Eranian on 1 Feb 2010 12:30
On Mon, Feb 1, 2010 at 5:45 PM, Peter Zijlstra <peterz(a)infradead.org> wrote:
> On Mon, 2010-02-01 at 17:14 +0100, Stephane Eranian wrote:
>
>> Using perfmon on Core 2 on a 10s noploop:
>>
>> pfmon -eunhalted_reference_cycles,unhalted_core_cycles,cpu_clk_unhalted:bus
>>  noploop 10
>> noploop for 10 seconds
>> 23869090125 UNHALTED_REFERENCE_CYCLES
>> 23849336873 UNHALTED_CORE_CYCLES
>>  2652122099 CPU_CLK_UNHALTED:BUS
>
> Weird, I used:
>
>  while :; do :; done &
>  while :; do :; done &
>  while :; do :; done &
>  while :; do :; done &
>  perf stat -a -e r013c -e r013c sleep 4
>  killall bash
>
> Which gives:
>
>  Performance counter stats for 'sleep 4':
>
>  244235699509090  raw 0x13c
>  244235695558036  raw 0x13c
>
Strange. I am running mine on a Q6600.
What's yours?

>    4.005485333  seconds time elapsed
>
> And verified it used fixed counter 2 and general purpose counter 0 using
> sysrq-p.
>
> [523417.108402] CPU#0:   gen-PMC0 ctrl:  000000000053013c
> [523417.108403] CPU#0:   gen-PMC0 count: 000000ff80019948
> [523417.108405] CPU#0:   gen-PMC0 left:  000000007fffffff
> [523417.108407] CPU#0:   gen-PMC1 ctrl:  0000000000000000
> [523417.108409] CPU#0:   gen-PMC1 count: 0000000000000000
> [523417.108411] CPU#0:   gen-PMC1 left:  000000007fffb8a8
> [523417.108412] CPU#0: fixed-PMC0 count: 0000000000000000
> [523417.108414] CPU#0: fixed-PMC1 count: 0000000000000000
> [523417.108416] CPU#0: fixed-PMC2 count: 0000010db1db2117
>
> Using -linus, since that doesn't have any of the recent constraint
> patches in that would avoid us from using fixed-PMC2.
>
>



--
Stephane Eranian | EMEA Software Engineering
Google France | 38 avenue de l'Opéra | 75002 Paris
Tel : +33 (0) 1 42 68 53 00
This email may be confidential or privileged. If you received this
communication by mistake, please
don't forward it to anyone else, please erase all copies and
attachments, and please let me know that
it went to the wrong person. Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Eranian on 1 Feb 2010 12:30
On Mon, Feb 1, 2010 at 5:47 PM, Peter Zijlstra <peterz(a)infradead.org> wrote:
> On Mon, 2010-02-01 at 17:12 +0100, Stephane Eranian wrote:
>> > btw, I've also added the below, from what I can make from the docs
>> fixed
>> > counter 2 is identical to arch perf event 0x013c, as per table A-1
>> and
>> > A-7. Both are called CPU_CLK_UNHALTED.REF, except for Core2, where
>> > 0x013c is called CPU_CLK_UNHALTED.BUS.
>> >
>>
>> If you measure 0x013c in a generic counter or in fixed counter 2
>> it will count the same thing but not at the same rate.
>> This is true on Core2, Atom, Nehalem, Westmere. The ratio is the
>> clock/bus ratio.
>
> But for Nehalem and Westmere event 0x3c umask 0x01 is referred to as
> CPU_CLK_UNHALTED.REF_P (Tables A-2 and A-4),
>
_P means programmable (counter).

on my NHM:

pfmon -v -eunhalted_core_cycles,unhalted_reference_cycles,cpu_clk_unhalted:ref_p
./noploop 10
[FIXED_CTRL(pmc16)=0xaa0 pmi0=1 en0=0x0 any0=0 pmi1=1 en1=0x2 any1=0
pmi2=1 en2=0x2 any2=0] UNHALTED_CORE_CYCLES UNHALTED_REFERENCE_CYCLES
[PERFEVTSEL0(pmc0)=0x51013c event_sel=0x3c umask=0x1 os=0 usr=1
anythr=0 en=1 int=1 inv=0 edge=0 cnt_mask=0] CPU_CLK_UNHALTED
noploop for 10 seconds

29292225749 UNHALTED_CORE_CYCLES
29292249954 UNHALTED_REFERENCE_CYCLES
1331465398 CPU_CLK_UNHALTED:REF_P

REF_P runs at 133MHz. Core at 2.93GHz.


> Fixed Counter 2 is referred to as CPU_CLK_UNHALTED.REF (Table A-7).
>
> For Core2 and Atom (Table A-8, A-9) it is called CPU_CLK_UNHALTED.BUS,
> for these entries there is talk about a fixed ratio.
>
>



--
Stephane Eranian | EMEA Software Engineering
Google France | 38 avenue de l'Opéra | 75002 Paris
Tel : +33 (0) 1 42 68 53 00
This email may be confidential or privileged. If you received this
communication by mistake, please
don't forward it to anyone else, please erase all copies and
attachments, and please let me know that
it went to the wrong person. Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 1 Feb 2010 12:50
On Mon, 2010-02-01 at 18:23 +0100, Stephane Eranian wrote:
> > 244235699509090 raw 0x13c
> > 244235695558036 raw 0x13c
> >
> Strange. I am running mine on a Q6600.
> What's yours?

These numbers came from a T9400, but my Q9450 does something similar.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Eranian on 1 Feb 2010 13:00
On Mon, Feb 1, 2010 at 6:46 PM, Peter Zijlstra <peterz(a)infradead.org> wrote:
> On Mon, 2010-02-01 at 18:23 +0100, Stephane Eranian wrote:
>> >  244235699509090  raw 0x13c
>> >  244235695558036  raw 0x13c
>> >
>> Strange. I am running mine on a Q6600.
>> What's yours?
>
> These numbers came from a T9400, but my Q9450 does something similar.
>
Are you sure you are reading from the correct corresponding data registers?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 1 Feb 2010 13:30
On Mon, 2010-02-01 at 18:56 +0100, Stephane Eranian wrote:
> On Mon, Feb 1, 2010 at 6:46 PM, Peter Zijlstra <peterz(a)infradead.org> wrote:
> > On Mon, 2010-02-01 at 18:23 +0100, Stephane Eranian wrote:
> >> > 244235699509090 raw 0x13c
> >> > 244235695558036 raw 0x13c
> >> >
> >> Strange. I am running mine on a Q6600.
> >> What's yours?
> >
> > These numbers came from a T9400, but my Q9450 does something similar.
> >
> Are you sure you are reading from the correct corresponding data registers?

It sure got me wondering, I'll go over that fixed counter code in
arch/x86/kernel/cpu/perf_event.c in the morning.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: [GIT PULL] regulator fix
Next: [PATCH v2 -stable 2.6.32.7] clocksource: fix compilation if no GENERIC_TIME