Date:	Fri, 1 Jul 2011 12:49:49 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Lin Ming <ming.m.lin@...el.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] perf: Intel uncore pmu counting support

On Fri, Jul 1, 2011 at 5:17 AM, Lin Ming <ming.m.lin@...el.com> wrote:
> On Fri, 2011-07-01 at 00:27 +0800, Stephane Eranian wrote:
>> On Thu, Jun 30, 2011 at 2:10 PM, Stephane Eranian <eranian@...gle.com> wrote:
>> > On Thu, Jun 30, 2011 at 10:09 AM, Lin Ming <ming.m.lin@...el.com> wrote:
>> >> Hi, all
>> >>
>> >> I posted uncore patches months ago, but it was pended due to an uncore
>> >> interrupt problem.
>> >>
>> >> This series are cut to support uncore pmu counting only.
>> >> So uncore interrupt handling is not needed.
>> >>
>> > You're making the assumption that when counting, you can never construct
>> > a measurement that will cause a counter to overflow the 39 bits. If not, then
>> > you need interrupt handling even when counting.
>> >
>> The actual counter width is 48. But wrmsrl() can only write the bottom 32 bits
>> of a register. I think Intel fixed that only with SandyBridge (see Vol3b). Thus,
>> the risk of 'silent' wrap around is much higher now as you have only 31 bits
>> to play with.
>
> I just tested wrmsrl on uncore counters and it's surprised to me that it
> supports full write.
>
>        val64.low  = 0xFFFFEEEE;
>        val64.high = 0x12345678;
>
> On Nehalem/Westmere:
>
>        msr = 0x3b0; //NHM_MSR_UNCORE_PMC0
>        wrmsrl(msr, val64.full & 0xfffffffffff); //48 bits counter
>        rdmsrl(msr, val64.full);
>        printfk("counter value: 0x%llx\n", val64.full);
>
> I got:
>        counter value: 0x5678ffffeeee
>
> On SandyBridge:
>
>        msr = 0x716; //SNB_MSR_UNC_CBO_1_PER_CTR0
>        wrmsrl(msr, val64.full & 0xfffffffffff); //44 bits counter
>        rdmsrl(msr, val64.full);
>        printfk("counter value: 0x%llx\n", val64.full);
>
> I got:
>        counter value: 0x678ffffeeee
>
I tried on my Nehalem and SandyBridge (model 42) and I get the same results.
The restriction applies only to core PMU counters then.

But what's so weird is that on SandyBridge the counter counters are still
limited:

uncore counter value: 0x678ffffeeee
   core counter value: 0xffffffffeeee

Yet, IA32_PERF_CAPABILITIES.FW_WIDTH (bit13) is set, thus wrmsrl()
should write the full 48-bit width (see Vol3b 30.2.2.3).

Further testing revealed that you get full width ONLY with the fixed counter
counters:

FW_WIDTH=1
uncore counter value: 0x678ffffeeee
core counter value: 0xffffffffeeee
fixed counter value: 0x678ffffeeee

I suspect there is a bug in the HW or a bogus description in the SDM.
I will check on that with Intel.


>> But if I read your patch correctly, it seems you are avoiding wrmsrl() on the
>> counter. Instead, you are reading it when you start (prev_count) and using
>> that value to compute the delta on stop.
>>
>> Am I understanding your workaround correctly?
>
> Yes, but I didn't realize that it's a workaround.
>
> Lin Ming
>
>>
>>
>> >
>> >> The uncore pmu type is allocated dynamically and exported via sysfs.
>> >> $ cat /sys/bus/event_source/devices/uncore/type
>> >> 6
>> >>
>> >> You can count uncore raw events as below,
>> >> $ perf stat -e uncore:r0101 ls
>> >>
>> >> It reads uncore pmu type id from sysfs to setup perf_event_attr::type.
>> >>
>> >> Comments are appreciated.
>> >>
>> >> Thanks,
>> >> Lin Ming
>> >>
>> >>
>> >
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists