Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752456AbbH1PQp (ORCPT ); Fri, 28 Aug 2015 11:16:45 -0400 Received: from mga11.intel.com ([192.55.52.93]:31725 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751779AbbH1PQo (ORCPT ); Fri, 28 Aug 2015 11:16:44 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,425,1437462000"; d="scan'208";a="550337376" 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//992ACAAIZkQA== Date: Fri, 28 Aug 2015 15:16:23 +0000 Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077018F4B62@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> <37D7C6CF3E00A74B8858931C1DB2F077018F4B39@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 t7SFGogr007123 Content-Length: 3010 Lines: 73 > On Fri, Aug 28, 2015 at 8:00 AM, Liang, Kan wrote: > > > > > >> 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. > > > I did not say that. Instead I said there is some benefits in having everything > under a power// PMU, including possibly portability to other non x86 > architectures. But the events in power// PMU will be per-socket or per-core. How should we handle it? What should we show in cpumask? ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?