Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751314AbbD3Ivm (ORCPT ); Thu, 30 Apr 2015 04:51:42 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:38266 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750778AbbD3Ivg (ORCPT ); Thu, 30 Apr 2015 04:51:36 -0400 Date: Thu, 30 Apr 2015 10:51:22 +0200 From: Peter Zijlstra To: Andy Lutomirski Cc: "linux-kernel@vger.kernel.org" , Len Brown , Paul Mackerras , Arnaldo Carvalho de Melo , Ingo Molnar Subject: Re: [RFC] x86, perf: Add an aperfmperf driver Message-ID: <20150430085122.GV5029@twins.programming.kicks-ass.net> References: <2c37309d20afadf88ad4a82cf0ce02b9152801e2.1430256154.git.luto@kernel.org> <20150429090941.GO5029@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2187 Lines: 52 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). > 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. -- 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/