Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751710AbbD3WJ7 (ORCPT ); Thu, 30 Apr 2015 18:09:59 -0400 Received: from mail-la0-f52.google.com ([209.85.215.52]:34205 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750717AbbD3WJ5 (ORCPT ); Thu, 30 Apr 2015 18:09:57 -0400 MIME-Version: 1.0 In-Reply-To: <20150430085122.GV5029@twins.programming.kicks-ass.net> References: <2c37309d20afadf88ad4a82cf0ce02b9152801e2.1430256154.git.luto@kernel.org> <20150429090941.GO5029@twins.programming.kicks-ass.net> <20150430085122.GV5029@twins.programming.kicks-ass.net> From: Andy Lutomirski Date: Thu, 30 Apr 2015 15:09:34 -0700 Message-ID: Subject: Re: [RFC] x86, perf: Add an aperfmperf driver To: Peter Zijlstra Cc: "linux-kernel@vger.kernel.org" , Len Brown , Paul Mackerras , Arnaldo Carvalho de Melo , Ingo Molnar 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: 2588 Lines: 63 On Thu, Apr 30, 2015 at 1:51 AM, Peter Zijlstra wrote: > On Wed, Apr 29, 2015 at 06:17:05PM -0700, Andy Lutomirski wrote: >> >> > + /* no sampling */ >> >> > + if (event->hw.sample_period) >> >> > + return -EINVAL; >> >> >> >> You could have set pmu::capabilities = >> >> PERF_PMU_CAP_NO_INTERRUPT which would also have killed that dead. >> > >> > >> > That checks attr.sample_period. I'm a bit confused about the >> > relationship between event->hw and event->attr. Do I not need to >> > check hw.sample_period? > > event->attr is the perf_event_attr used to instantiate the event. > event->hw is the hardware/working state of the event. > > You'll notice that attr::sample_period is part of a union and when > !attr::freq will be used as the actual hw::sample_period. However when > attr::freq we'll compute hw::sample_period based on actual event rates > such that we'll approx attr::sample_freq. > > Setting pmu::capabilities = PERF_PMU_CAP_NO_INTERRUPT would be the best > solution here. > >> > Before I submit v2, do you think this is actually worth doing? I can >> > see it being useful for answering questions like "did this workload >> > end up running at full speed". >> > >> >> To clarify, this is partially redundant with "cpu-cycles" and >> "ref-cycles". That being said, these are simpler, actually documented >> as being appropriate for measuring cpu performance states, and don't >> have any scheduling constraints. > > On the whole useful question; I dunno. It seems like something worth > providing for the reasons you state. But I don't really get around to > doing much userspace these days so I might not be the best to answer > this. > > Also, you could extend this with IA32_PPERF (Skylake and later, see > SDM-201501 book 3 section 14.4.5.1). Interesting. I can't test it for obvious reasons, and the enumeration is not really straightforward, since it's non-architectural. If I send the patch, can you test? Should the PMU still be called aperfmperf? > >> Also, is perf stat able to count while idle? perf stat -a -e >> cpu-cycles sleep 1 reports very small numbers. > > Yes, perf stat -a (iow cpu events) should count while idle, note however > that not all events count during halt, so its very much event dependent. I see. MPERF, etc only count in C0. --Andy -- 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/