From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S940857AbdEXQCd (ORCPT ); Wed, 24 May 2017 12:02:33 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:35294 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S939021AbdEXQCA (ORCPT ); Wed, 24 May 2017 12:02:00 -0400 From: Vince Weaver X-Google-Original-From: Vince Weaver Date: Wed, 24 May 2017 12:01:50 -0400 (EDT) X-X-Sender: vince@macbook-air To: Andi Kleen cc: Stephane Eranian , Peter Zijlstra , "Liang, Kan" , "mingo@redhat.com" , "linux-kernel@vger.kernel.org" , "alexander.shishkin@linux.intel.com" , "acme@redhat.com" , "jolsa@redhat.com" , "torvalds@linux-foundation.org" , "tglx@linutronix.de" , "vincent.weaver@maine.edu" Subject: Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter In-Reply-To: <20170524154518.GA24144@tassilo.jf.intel.com> Message-ID: References: <1495213582-3635-1-git-send-email-kan.liang@intel.com> <20170522091916.3gydvflk4fnqkzw5@hirez.programming.kicks-ass.net> <37D7C6CF3E00A74B8858931C1DB2F077536F079F@SHSMSX103.ccr.corp.intel.com> <20170522192335.v4gvhz24ix2jeihg@hirez.programming.kicks-ass.net> <20170523063913.363ssgcy7kmeesye@hirez.programming.kicks-ass.net> <20170524154518.GA24144@tassilo.jf.intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 May 2017, Andi Kleen wrote: > > Right, I did not even consider the rdpmc, but yeah, you will get a count that > > is not relevant to the user visible event. Unless you fake it using the time > > scaling fields there but that's ugly. > > Could add another scaling field to the mmap page for this. The whole point of the rdpmc() implementation is to be low overhead. If you have to parse 10 different mmap() fields it starts to defeat the purpose. I already have people really grumpy that you have to have one mmap() page per event, meaning you sacrifice one TLB entry for each event you are measuring. If the watchdog counter is constantly running, can't you just modify perf_event to just grab start/stop values at context switch time and provide the difference to the user? Sort of like the "always running" patchsets that float around? Though I guess that doesn't help much with sampling. Vince