From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753538AbcLFPrq convert rfc822-to-8bit (ORCPT ); Tue, 6 Dec 2016 10:47:46 -0500 Received: from mga04.intel.com ([192.55.52.120]:26568 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752198AbcLFPrp (ORCPT ); Tue, 6 Dec 2016 10:47:45 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,310,1477983600"; d="scan'208";a="39587828" From: "Liang, Kan" To: Peter Zijlstra CC: "mingo@redhat.com" , "acme@kernel.org" , "linux-kernel@vger.kernel.org" , "alexander.shishkin@linux.intel.com" , "tglx@linutronix.de" , "namhyung@kernel.org" , "jolsa@kernel.org" , "Hunter, Adrian" , "wangnan0@huawei.com" , "mark.rutland@arm.com" , "andi@firstfloor.org" Subject: RE: [PATCH V2 03/13] perf/x86: output sampling overhead Thread-Topic: [PATCH V2 03/13] perf/x86: output sampling overhead Thread-Index: AQHSTOHSuMQJFJKXz0+jqt27jlukiaD6RYyAgADDP4D//4M1AIAAhmxQ Date: Tue, 6 Dec 2016 15:47:40 +0000 Message-ID: <37D7C6CF3E00A74B8858931C1DB2F07750CA9EFB@SHSMSX103.ccr.corp.intel.com> References: <1480713561-6617-1-git-send-email-kan.liang@intel.com> <1480713561-6617-4-git-send-email-kan.liang@intel.com> <20161206112013.GJ3124@twins.programming.kicks-ass.net> <37D7C6CF3E00A74B8858931C1DB2F07750CA9EAE@SHSMSX103.ccr.corp.intel.com> <20161206153222.GB3061@worktop.programming.kicks-ass.net> In-Reply-To: <20161206153222.GB3061@worktop.programming.kicks-ass.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYWE1YTFmM2UtMmJjOS00OTI3LWIwZDEtNWQ0MWEwY2Y3ZGIzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjVXOG5HdHZROTlEcVA4QUNCZG1FK1pqWlVNOFB3VUtqR0xmakhOYVBiZVE9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Tue, Dec 06, 2016 at 03:02:20PM +0000, Liang, Kan wrote: > > > > > > > On Fri, Dec 02, 2016 at 04:19:11PM -0500, kan.liang@intel.com wrote: > > > > From: Kan Liang > > > > > > > > On x86, NMI handler is the most important part which brings > > > > overhead for sampling. Adding a pmu specific overhead type > > > > PERF_PMU_SAMPLE_OVERHEAD for it. > > > > > > > > For other architectures which may don't have NMI, the overhead > > > > type can be reused. > > > > > > > > Signed-off-by: Kan Liang > > > > --- > > > > arch/x86/events/core.c | 17 ++++++++++++++++- > > > > arch/x86/events/perf_event.h | 2 ++ > > > > include/uapi/linux/perf_event.h | 1 + > > > > 3 files changed, 19 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index > > > > 9d4bf3a..de40f96 100644 > > > > --- a/arch/x86/events/core.c > > > > +++ b/arch/x86/events/core.c > > > > @@ -1397,6 +1397,9 @@ static void x86_pmu_del(struct perf_event > > > > *event, int flags) > > > > > > > > perf_event_update_userpage(event); > > > > > > > > + if ((flags & PERF_EF_LOG) && cpuc->nmi_overhead.nr) > > > > + perf_log_overhead(event, PERF_PMU_SAMPLE_OVERHEAD, > > > > +&cpuc->nmi_overhead); > > > > + > > > > do_del: > > > > if (x86_pmu.del) { > > > > /* > > > > > > That's not at all mentioned in the changelog, and it clearly isn't > > > nmi_overhead. > > > > Here it only records the overhead, not calculate. > > It doesn't record anything, it generates the output. And it doesn't explain > why that needs to be in pmu::del(), in general that's a horrible thing to do. Yes, it only generate/log the output. Sorry for the confused wording. The NMI overhead is pmu specific overhead. So the NMI overhead output should be generated in pmu code. I assume that the pmu:del is the last called pmu function when perf finish. Is it a good place for logging? Thanks, Kan