Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752666AbbH1PA5 (ORCPT ); Fri, 28 Aug 2015 11:00:57 -0400 Received: from mga03.intel.com ([134.134.136.65]:51135 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752471AbbH1PAz (ORCPT ); Fri, 28 Aug 2015 11:00:55 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,425,1437462000"; d="scan'208";a="777531242" 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//iUWAgB5jfRCAA+VOgIAAhtig Date: Fri, 28 Aug 2015 15:00:47 +0000 Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077018F4B39@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> <37D7C6CF3E00A74B8858931C1DB2F077018F2AD6@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 t7SF14eF006960 Content-Length: 2466 Lines: 60 > On Tue, Aug 25, 2015 at 1:15 PM, Liang, Kan wrote: > > > >> >> > > >> >> I understand that these metrics are useful and needed however if I > >> >> look at the broader picture I see many PMUs doing similar things > >> >> or appearing different when they are actually very close. It would > >> >> be nice to have a more unified approach. You have RAPL (client, > >> >> server) which appears as the power PMU. You have the PCU uncore > on > >> >> servers which also provides C-state residency info. Yet, all these > >> >> appear differently and expose events with different names. > >> >> I think we could benefit from a more unifie approach here such > >> >> that you would be able to do > >> >> > >> >> $ perf stat -a -e power/c6-residency/, power/energy-pkg/ > >> >> > >> >> on client and server without having to change the pmu name of the > >> >> event names. > >> > > >> > Yes, I agree. I'll think about it. > >> > > > > > Hi Stephane, > > > > I thought more about your suggestion regarding to create a unified > > power PMU for all related events include RAPL and residency. > > It looks we can benefit from a simple unified name, but it also brings > > too much confusion. > > - cstate residency is the time of the core/socket in specific cstate. > > While RAPL event is the power core/socket which consumed. > > They have different concepts. > > - cstate residency includes both per-core and per-socket events. > > RAPL events is only per-socket. So the CPU mask is different. > > It's very confused that the events in same PMU has different CPU > mask. > > > > So I think it should be better to use different PMUs for RAPL and > residency. > > > > What do you think? > > > Well, you are maybe confusing events with PMU. If you look at the core > PMU, it cover many events measuring vastly different aspects of the core. > Some events are per-thread, others are per-core. > > Here, I was thinking it would be good to have some power// PMU with > many events covering cstate residency, energy consumption. And yes, > some events would be per-socket, others per-core. So you agree to create two new cstate PMUs (per-core and per-socket) to cover cstate residency? If so, I will start to implement the V3 version for two new PMUs. Thanks, Kan ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?