Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755634AbbHFVpm (ORCPT ); Thu, 6 Aug 2015 17:45:42 -0400 Received: from mga09.intel.com ([134.134.136.24]:45587 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753418AbbHFVpl (ORCPT ); Thu, 6 Aug 2015 17:45:41 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,625,1432623600"; d="scan'208";a="743713823" From: "Liang, Kan" To: Stephane Eranian CC: Peter Zijlstra , "mingo@redhat.com" , Arnaldo Carvalho de Melo , "ak@linux.intel.com" , LKML Subject: RE: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support Thread-Topic: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support Thread-Index: AQHQyIV8gIooX1MBqECTD6kaMyULcJ3+pmIAgAAp4ICAAIlEYP//iUWAgACHTsD//4g1AIAAhsrg//9/a4AAEVTCMA== Date: Thu, 6 Aug 2015 21:45:30 +0000 Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077018D342E@SHSMSX103.ccr.corp.intel.com> References: <1437986776-8438-1-git-send-email-kan.liang@intel.com> <20150806154424.GR19282@twins.programming.kicks-ass.net> <37D7C6CF3E00A74B8858931C1DB2F077018D334D@SHSMSX103.ccr.corp.intel.com> <37D7C6CF3E00A74B8858931C1DB2F077018D3373@SHSMSX103.ccr.corp.intel.com> <37D7C6CF3E00A74B8858931C1DB2F077018D33A7@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t76LjlDX018248 Content-Length: 2053 Lines: 54 > -----Original Message----- > From: Stephane Eranian [mailto:eranian@google.com] > Sent: Thursday, August 06, 2015 4:38 PM > To: Liang, Kan > Cc: Peter Zijlstra; mingo@redhat.com; Arnaldo Carvalho de Melo; > ak@linux.intel.com; LKML > Subject: Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs > support > > On Thu, Aug 6, 2015 at 1:25 PM, Liang, Kan wrote: > > > >> >> >> >> +static cpumask_t power_cstate_core_cpu_mask; > >> >> >> > > >> >> >> > That one typically does not need a cpumask. > >> >> >> > > >> >> >> You need to pick one CPU out of the multi-core. But it is for > >> >> >> client parts thus there is only one socket. At least this is my > >> understanding. > >> >> >> > >> >> > > >> >> > CORE_C*_RESIDENCY are available for physical processor core. > >> >> > So logical processor in same physical processor core share the > >> >> > same counter. > >> >> > I think we need the cpumask to identify the default logical > >> >> > processor which do counting. > >> >> > > >> >> Did you restrict these events to system-wide mode only? > >> >> > >> Ok, so that means that your cpumask includes one HT per physical core. > >> But then, the result is not the simple aggregation of all the N/2 CPUs. > > > > The counter counts per physical core. The result is the aggregation of > > all HT cpus in same physical core. > > But then don't you need to divide by 2 to get a meaningful result? Rethink of it. I think I was unclear about the aggregation of all HT cpus in same physical core. physical core Cstate should equal to min(logical core C-state). So only all logical core enters C6-state, the physical core enters C6-state, then CORE_C6_RESIDENCY counts. So if we only count on one logical core/HT for CORE_C6_RESIDENCY. We don't need to divide by 2. The count result is the residency when all logical core in C6 (some may deeper). Thanks, Kan ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?