[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FE03585.1040103@intel.com>
Date: Tue, 19 Jun 2012 16:17:09 +0800
From: "Yan, Zheng" <zheng.z.yan@...el.com>
To: Stephane Eranian <eranian@...gle.com>
CC: a.p.zijlstra@...llo.nl, mingo@...e.hu, jolsa@...hat.com,
andi@...stfloor.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V6 08/13] perf: Add Sandy Bridge-EP uncore support
On 06/19/2012 03:18 PM, Stephane Eranian wrote:
> On Tue, Jun 19, 2012 at 2:59 AM, Yan, Zheng <zheng.z.yan@...el.com> wrote:
>> On 06/18/2012 11:28 PM, Stephane Eranian wrote:
>>> On Fri, Jun 15, 2012 at 8:31 AM, Yan, Zheng <zheng.z.yan@...el.com> wrote:
>>>>> From: "Yan, Zheng" <zheng.z.yan@...el.com>
>>>>>
>>>>> Add Intel Nehalem and Sandy Bridge uncore pmu support. The uncore
>>>>> subsystem in Sandy Bridge-EP consists of 8 components (Ubox,
>>>>> Cacheing Agent, Home Agent, Memory controller, Power Control,
>>>>> QPI Link Layer, R2PCIe, R3QPI).
>>>>>
>>> I did not find in this patch the support for the C-Box Filter register
>>> (SNBEP_C0_MSR_PMON_BOX_FILTER). Based on the description
>>> in the manual, looks like a valuable filter to support, especially for
>>> the core/thread filtering capability.
>>>
>>> There is only one such filter per box, and it can be used by any events.
>>> So looks like we have another offcore_resp style register to manage
>>> here. Need to ensure the value of that filter is shared by all 4 counters.
>>> If you were to support that, you'd have to enable the tid filter on the
>>> CBox config regs and export that via sysfs. Also I assume you'd
>>> pass the value of that filter either in config1 or in the upper 32 bits
>>> of the config reg.
>>>
>>> What's your take on that?
>>>
>>
>> I'm working on uncore support for Nehalem-EX which has extensive use of
>> shared extra registers. Once that work done, adding C-Box filter support
>> should be easy.
>>
> Ok. Note that the code logic to handle shared regs is already there and is
> used for OFFCORE_RSP*, LBR_SELECT and LD_LAT (soon). Would be
> nice to reuse that framework for this as well. Though I understand you're
> looking at per box sharing as opposed to per physical core sharing or
> cross HT sharing.
>
The use of shared extra registers in Nehalem-EX uncore is more complex.
Some events require programming two extra registers. Some extra registers
have several fields, each field is for different event. I don't think I
can reuse that framework.
Regards
Yan, Zheng
--
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