Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755568AbbHFXKJ (ORCPT ); Thu, 6 Aug 2015 19:10:09 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:33586 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755009AbbHFXKE (ORCPT ); Thu, 6 Aug 2015 19:10:04 -0400 MIME-Version: 1.0 In-Reply-To: <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> <37D7C6CF3E00A74B8858931C1DB2F077018D342E@SHSMSX103.ccr.corp.intel.com> Date: Thu, 6 Aug 2015 16:10:02 -0700 Message-ID: Subject: Re: [PATCH V2 1/1] perf/x86: Add Intel power cstate PMUs support From: Stephane Eranian To: "Liang, Kan" Cc: Peter Zijlstra , "mingo@redhat.com" , Arnaldo Carvalho de Melo , "ak@linux.intel.com" , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2496 Lines: 60 On Thu, Aug 6, 2015 at 2:45 PM, Liang, Kan wrote: > > >> -----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). > Ok and here you are assuming you are only measuring one logical CPU per physical core. If this is the case, then I think you are alright. But I wonder what you'd get when perf stat -a aggregates across all measured CPUs, i.e., one CPU per core. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/