[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBRZf41wbJKq2PCdMzDhgNMn0VYkVsaZToS34AXpRzTGLw@mail.gmail.com>
Date: Thu, 30 Jun 2011 18:27:40 +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 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.
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?
>
>> 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