From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 643ADC47257 for ; Thu, 7 May 2020 17:48:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4B52820643 for ; Thu, 7 May 2020 17:48:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728056AbgEGRsh (ORCPT ); Thu, 7 May 2020 13:48:37 -0400 Received: from mga01.intel.com ([192.55.52.88]:26136 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726393AbgEGRsg (ORCPT ); Thu, 7 May 2020 13:48:36 -0400 IronPort-SDR: rJCF1nCYdeGGqwiQ9w4IJDvSipRRgKnHw7dz4VS9dNTKKVOPy34fCUPcoZ2F2+EMFaUVpRQUtg DTms4HLsWFmQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2020 10:48:36 -0700 IronPort-SDR: n+wnT7yQJKWW2P4uJXN3jxTgi9+UwRapDpTr3iblt8rCQtRCqnTDxbaOqU0Y1naHjEx+FhhC4r SzYipRyvdyhQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,364,1583222400"; d="scan'208";a="435378020" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.21]) by orsmga005.jf.intel.com with ESMTP; 07 May 2020 10:48:35 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id D31B9301C1B; Thu, 7 May 2020 10:48:35 -0700 (PDT) Date: Thu, 7 May 2020 10:48:35 -0700 From: Andi Kleen To: Ian Rogers Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , Kajol Jain , John Garry , Jin Yao , Kan Liang , Cong Wang , Kim Phillips , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, Stephane Eranian Subject: Re: [RFC PATCH 0/7] Share events between metrics Message-ID: <20200507174835.GB3538@tassilo.jf.intel.com> References: <20200507081436.49071-1-irogers@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200507081436.49071-1-irogers@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 07, 2020 at 01:14:29AM -0700, Ian Rogers wrote: > Metric groups contain metrics. Metrics create groups of events to > ideally be scheduled together. Often metrics refer to the same events, > for example, a cache hit and cache miss rate. Using separate event > groups means these metrics are multiplexed at different times and the > counts don't sum to 100%. More multiplexing also decreases the > accuracy of the measurement. > > This change orders metrics from groups or the command line, so that > the ones with the most events are set up first. Later metrics see if > groups already provide their events, and reuse them if > possible. Unnecessary events and groups are eliminated. Note this actually may make multiplexing errors worse. For metrics it is often important that all the input values to the metric run at the same time. So e.g. if you have two metrics and they each fit into a group, but not together, even though you have more multiplexing it will give more accurate results for each metric. I think you change can make sense for metrics that don't fit into single groups anyways. perf currently doesn't quite know this but some heuristic could be added. But I wouldn't do it for simple metrics that fit into groups. The result may well be worse. My toplev tool has some heuristics for this, also some more sophisticated ones that tracks subexpressions. That would be far too complicated for perf likely. -Andi From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [RFC PATCH 0/7] Share events between metrics Date: Thu, 7 May 2020 10:48:35 -0700 Message-ID: <20200507174835.GB3538@tassilo.jf.intel.com> References: <20200507081436.49071-1-irogers@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20200507081436.49071-1-irogers@google.com> Sender: linux-kernel-owner@vger.kernel.org To: Ian Rogers Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , Kajol Jain , John Garry , Jin Yao , Kan Liang , Cong Wang Kim List-Id: linux-perf-users.vger.kernel.org On Thu, May 07, 2020 at 01:14:29AM -0700, Ian Rogers wrote: > Metric groups contain metrics. Metrics create groups of events to > ideally be scheduled together. Often metrics refer to the same events, > for example, a cache hit and cache miss rate. Using separate event > groups means these metrics are multiplexed at different times and the > counts don't sum to 100%. More multiplexing also decreases the > accuracy of the measurement. > > This change orders metrics from groups or the command line, so that > the ones with the most events are set up first. Later metrics see if > groups already provide their events, and reuse them if > possible. Unnecessary events and groups are eliminated. Note this actually may make multiplexing errors worse. For metrics it is often important that all the input values to the metric run at the same time. So e.g. if you have two metrics and they each fit into a group, but not together, even though you have more multiplexing it will give more accurate results for each metric. I think you change can make sense for metrics that don't fit into single groups anyways. perf currently doesn't quite know this but some heuristic could be added. But I wouldn't do it for simple metrics that fit into groups. The result may well be worse. My toplev tool has some heuristics for this, also some more sophisticated ones that tracks subexpressions. That would be far too complicated for perf likely. -Andi