Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp4442505pxb; Tue, 31 Aug 2021 05:27:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznTAJ+PQ7BS8AryMmxqMT6SnmXvD1hgSxAw1GDSO1iLOkEupHKc9jinAZkW31lhfGWtVmw X-Received: by 2002:a05:6602:38e:: with SMTP id f14mr2831362iov.62.1630412847972; Tue, 31 Aug 2021 05:27:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630412847; cv=none; d=google.com; s=arc-20160816; b=pwVO16UfZYgskeuEAazDn8Ju6/tf315h1Ejmnm8D1V6q9B5gbXTL6Orc1YhuRr3njP Olzbqx5gdx8rlNuzIbxR8p+ShB56mqTWfd6+NN97R7pGTseKgFOTnfVlIN66ZU63RksC iAc+fQn9LOIp/7+rAJC5X2kXCnBzD4LhHAbGhnwVREHX6r1Jy/EYXESL6ZwadialpIz3 Pc2Y64cGEla5w1g+l+odm7k+FrJEBYuLXyDSl0RdZyDy/YjH7s8Rre8h35ivg9gSAPjT SoB3v9Jdff7QMQbKcW6btJzW3JmIJxtZmSP/DfVeGq+fRM8rN6aweSQOjr2JHVq6S+6y vjUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=L+wc30ZHstHOgN0d2A40H0V8qG5hqCqSseO/vjIzQeI=; b=VR/v/Wfxx/Wp5tu1CkpbfD8rYEyEBMeUs8k1FbOVsXEVGn0ejHhRsSP/Idq8NDgF6t fS1jIYoSb5b2eWI6vGYsEH9+IV74cEVD/DZoDLJBUnNP0isJoqOYG/yXQc++qGiRxnph jTt0MUhYKYULLkbYmdAqCvlhgoYbpnfEugKDr2Go3vys8+PEooT8ucq6ZTszcVQX7YZ2 Hz4sqGy1QoHGru73yyKA688gRBqa9zbwhWDhAMXq3nxS5H0HY25H3qpIRfXKttaMjFHk BQwWP/Nx8Eig3spdrU+z0E1tf+zqcVWgNnsneiafQcBIWwJKbCTB+CDAANuFROTqqeTb Vf4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=V8KrWXSI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k39si17892304jav.114.2021.08.31.05.27.15; Tue, 31 Aug 2021 05:27:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=V8KrWXSI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230013AbhHaM13 (ORCPT + 99 others); Tue, 31 Aug 2021 08:27:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:55626 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229677AbhHaM11 (ORCPT ); Tue, 31 Aug 2021 08:27:27 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C4FA86103A; Tue, 31 Aug 2021 12:26:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630412792; bh=L+wc30ZHstHOgN0d2A40H0V8qG5hqCqSseO/vjIzQeI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=V8KrWXSIxltiT/VmdhuBukXaYqmMi/3ARbqLpeIrF4GUjbqMJteuFzFb2KkQyhv2f //KfP3gntswmeRlN2zSxvVamJLDVwgEQ6zjVJr/veASS4ezbubbZsfawPmN8EeEBhX TeZew8nwMqiBeBOJDFDZr3DdEA6r1vKCXG+UZpf/pJc/ene1nYyCS5MTd3kBH4MMEw Q+G0IZbrzrw56jx0KonaEiU3+I4NfwbruK8chneFOmRniUoKhlnCQPViuqpndD1UM4 iwcaiIvNotb9zvUSB3ZCfkvD6LEEYZ3dyXbeL0P8Kxh4fYTBUiAKExA6kNtOQYgRrj SgnXOVsj2cqfg== Received: by mail-ej1-f47.google.com with SMTP id u3so38147471ejz.1; Tue, 31 Aug 2021 05:26:32 -0700 (PDT) X-Gm-Message-State: AOAM533QkRosyrpGoppxQdMfK9hqcX0Z9BPxdx7nkCw95vwbuAUoE5Qc rGqZfPQGeS3xhzQh62JK6eBmFy3T+Ai368Xj5w== X-Received: by 2002:a17:906:b4d:: with SMTP id v13mr31303236ejg.468.1630412791360; Tue, 31 Aug 2021 05:26:31 -0700 (PDT) MIME-Version: 1.0 References: <20210820093908.734503-1-nakamura.shun@fujitsu.com> <20210820093908.734503-2-nakamura.shun@fujitsu.com> In-Reply-To: From: Rob Herring Date: Tue, 31 Aug 2021 07:26:18 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] libperf: Add processing to scale the counters obtained during the read() system call when multiplexing To: "nakamura.shun@fujitsu.com" Cc: "peterz@infradead.org" , "mingo@redhat.com" , "acme@kernel.org" , "mark.rutland@arm.com" , "alexander.shishkin@linux.intel.com" , "jolsa@redhat.com" , "namhyung@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-perf-users@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 24, 2021 at 5:12 AM nakamura.shun@fujitsu.com wrote: > > Hi, Rob > > > On Fri, Aug 20, 2021 at 06:39:06PM +0900, Shunsuke Nakamura wrote: > > > perf_evsel__read() scales counters obtained by RDPMC during multiplexing, but > > > does not scale counters obtained by read() system call. > > > > > > Add processing to perf_evsel__read() to scale the counters obtained during the > > > read() system call when multiplexing. > > > > Which one is right though? Changing what read() returns could break > > users, right? Or are you implying that the RDPMC path is correct and > > read() was not. More likely the former case since I wrote the latter. > > perf_evsel__read() returns both the count obtained by RDPMC and the count obtained > by the read() system call when multiplexed with RDPMC enabled. > > That is, there is a mix of scaled and unscaled values. > > As Rob says, when this patch is applied, rescaling the count obtained from > perf_evsel__read() during multiplexing will break the count. > > I think the easiest solution is to change the value you get from RDPMC to not scale > and let the user scale it, but I thought it would be a little inconvenient. Agreed, unless someone else has an opinion. It would be good to do the scaling in libperf with the optimized math op, but I assume there's some reason the user may need unscaled values? Rob