Messages in this thread | | | Date | Tue, 19 Jun 2012 16:17:09 +0800 | From | "Yan, Zheng" <> | 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@intel.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@intel.com> wrote: >>>>> From: "Yan, Zheng" <zheng.z.yan@intel.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
| |