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;
From:   "nakamura.shun@fujitsu.com" <nakamura.shun@fujitsu.com>
To:     Ian Rogers <irogers@google.com>
CC:     "peterz@infradead.org" <peterz@infradead.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "acme@kernel.org" <acme@kernel.org>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "alexander.shishkin@linux.intel.com" 
        <alexander.shishkin@linux.intel.com>,
        "jolsa@redhat.com" <jolsa@redhat.com>,
        "namhyung@kernel.org" <namhyung@kernel.org>,
        Rob Herring <robh@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>
Subject: Re: [PATCH 1/3] libperf: Add processing to scale the counters
 obtained during the read() system call when multiplexing
Thread-Topic: [PATCH 1/3] libperf: Add processing to scale the counters
 obtained during the read() system call when multiplexing
Thread-Index: AQHXmFsxBFGvQYUD8Uu1pPLYL2hYdauCbgJwgAsoEwCAC8IOAIAOquyD
Date:   Fri, 17 Sep 2021 08:04:04 +0000
Message-ID: <OSBPR01MB460074286BDE891952CBC809F7DD9@OSBPR01MB4600.jpnprd01.prod.outlook.com>
References: <20210820093908.734503-1-nakamura.shun@fujitsu.com>
 <20210820093908.734503-2-nakamura.shun@fujitsu.com>
 <YSQBI+FZLBvKr088@robh.at.kernel.org>
 <OSBPR01MB4600288E176A169C07BF543EF7C59@OSBPR01MB4600.jpnprd01.prod.outlook.com>
 <CAL_JsqLKD0DZT63MQ9vTumOf1bfRrU9Bt9Qa_GTb1siRsK+Z+g@mail.gmail.com>
 <CAP-5=fW_g9JHKWQoNiwNeSN8MjJ1OA7qLb3JD3ErEi1be4DEiQ@mail.gmail.com>
In-Reply-To: <CAP-5=fW_g9JHKWQoNiwNeSN8MjJ1OA7qLb3JD3ErEi1be4DEiQ@mail.gmail.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
msip_labels: MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_Enabled=True;MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_SiteId=a19f121d-81e1-4858-a9d8-736e267fd4c7;MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_SetDate=2021-09-17T08:04:03.720Z;MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_Name=FUJITSU-RESTRICTED;MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_ContentBits=0;MSIP_Label_a7295cc1-d279-42ac-ab4d-3b0f4fece050_Method=Standard;
suggested_attachment_session_id: c4bd3b24-7c4f-2cd6-8312-17b67fd49c50
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fb9bc903-8228-4ad6-7bc1-08d979b1b75b
x-ms-traffictypediagnostic: OSBPR01MB2040:
x-microsoft-antispam-prvs: <OSBPR01MB20401A33F908BF955A7B3431F7DD9@OSBPR01MB2040.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RrK++4tdrXm3FhZLL8fwzVsNoazMi1iGZItXqUyW78LZQSxQmf2UZSpy4dbbuM98SOWWrKpPenbIS3tbvG5QOp/ex1SexQolMeG1gHI0zxR2/cV+iwvmjP3wY3uR5Xr0FqwGnDvQmgVS9fpdDhfoIjXfGygQlP/MA4yyBj00bfAcf+/rKdRUeaD+BvZL053Ckf2s7h1WHuB+ynTNNYEHObj0Kj3crA/8sMBlFxeCPxms3lR/5OGB3uEFXwRMFSNBxGwBCZKPUTaBCT1t0Q7glIhg/XX0d9yK1B8cKJVqFGV/3WtAg20abmEVr51e8KrZhtHTggwG0obpyNNjtxEAGq9WNk3y2RWvrPGu7iYMmZn6i/o4PaHoe87aqc8W3Qxtj5LmEVhDyzbDF3SNslmvU1SWaT2ueZddVUmjARrEfGebN4PF6jr72MJ2D5S9AJXEaJrL7HXefNHmK5Gv8Uo4AZbh91MBjQTkuCGpZAqrmGpyKEPicnW8LvD28NnI1D9jYkfaelkKzAfbfg+z+KYNyff2TP49EzBimt1WziFaq0GroIKAOMCR0BlfBcl6FT47r4QmTAg8wSgNWxs8vNl+iJQ2wzgFeuRkBbK8BnVJ1OoPLLoqtzHxsv2Mfuj2qizf65J3NQJH0d65z/KYYjD39Ct+EqF9Abt3Qiw9p7FJdahNqApDAr3juChC6izVsaM6/0oiiamK03shYfdw6eislQ==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OSBPR01MB4600.jpnprd01.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(66476007)(85182001)(66946007)(38070700005)(53546011)(2906002)(6506007)(38100700002)(7416002)(316002)(76116006)(122000001)(64756008)(66556008)(66446008)(8936002)(86362001)(508600001)(33656002)(71200400001)(4326008)(54906003)(7696005)(9686003)(5660300002)(26005)(52536014)(186003)(6916009)(8676002)(55016002);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?VUVjNjI2MmIrTXRhaDB5NGNaYXpUdjJ1TkRWUkowNFNiVk1LYUFERVc4?=
 =?iso-2022-jp?B?QTNZMTd2S3A1bmY1T0x5OTdOa0lEaW5XQTdVbEptTkdRVzdsK1hqc1BI?=
 =?iso-2022-jp?B?WXJGVklvR2tvemRodTArenlhM3hHZ3N6M0dXLzVOZ2F1MTRYRnlEMUZU?=
 =?iso-2022-jp?B?Qnh5cFVrNkJ4VEZNVVg4SFJJVkR1MDRnMjdLU0VQMEEwNkxQdm5oVitR?=
 =?iso-2022-jp?B?VUlkeUVYMFNSVzVXaEh0LzlyaTJwbnVFemdMQTRKWmZVaXl0NFZRS1NY?=
 =?iso-2022-jp?B?MENVZjhDdzFtZHY5RVk2MWNZR3ByNTN0bk1MR3NFQW5vTUwvdkFIV3Z3?=
 =?iso-2022-jp?B?eXFyNDNTMUVDMUdaQ05YV3RhbFk5TUpIYWNGVVZkcU1Mdy9HSE1aSFd2?=
 =?iso-2022-jp?B?TkhrR0ZKR01xRFBYUXJtUGEzM0JFWmhoMUx2ZVlSWU9kYkI4S1ZiQWQ2?=
 =?iso-2022-jp?B?dWpWSDk3UDMxUi9qSE5tTWNlNE13dFFpVFA1cStiWEREbEEvanpQWXVW?=
 =?iso-2022-jp?B?eFRzbnFZV2Q5NUkrY0tYcWpzV1M1RzA5eDhuNGJJS3U5VUI2MFNBV0Z2?=
 =?iso-2022-jp?B?SDNUTW5VRWpydDl0dUZ2WTdMRnNqZkU4aC9ZMlNMWmdRa3hXNFpOYmMz?=
 =?iso-2022-jp?B?V3R3SDNOYlhTYjkrN2VLTjNDbFBJbUVlWE1McGFjbTBZdjJsK005Ritk?=
 =?iso-2022-jp?B?VUZ0RTlQS1AxZkVRdkNnelkxckNDZ3M5ZFBaa3Y1ZytTNW1iVDl1a0tq?=
 =?iso-2022-jp?B?dVozS2FYS1RUbTcyNHpqWmpBeEVzVElIWENCeTJNVlFuWFFXNUt0MllM?=
 =?iso-2022-jp?B?MXZxMHlLTDlLd0JEaUgyRy9zM3lUTVRFdWFwZ0Z3SUN3OEhPOUVIelhV?=
 =?iso-2022-jp?B?NkRPaWl0UHppeS8vTmRncyt2VS84ejdrbFhrc1QvU25udTF4cDB6ZTNY?=
 =?iso-2022-jp?B?QVdzU2dZZzFrNFdJNG1iRzBkM2UyTFIvZ1Y5UTgxYjlVV1Z0MDFIT1Zn?=
 =?iso-2022-jp?B?UnBpVlJYVVFPTjZtd0Zkd0VmbnNoU1JXeHN1STJwNEs5VWEyVkI4dzlQ?=
 =?iso-2022-jp?B?T3ozeG5JOEYyajErUy9LYmhvM3IwSjBzRGNReDl3eURZempCMmwvLzQv?=
 =?iso-2022-jp?B?cHF1OTlLVmpOR1NhSExUb2xOWlhJSFBhZUg3aEY1b2tndGJhclNyUUdr?=
 =?iso-2022-jp?B?TU04cmpKMlFSbjhyOXZQUjFyUDQ3aW9YY3JpTVFpOFVFcm9rMklaSzM1?=
 =?iso-2022-jp?B?aXdpMWZBa281bmR1S3EwOUYvM0xXaW1HSW5uTzd1ZXd2U1pQdVVnNi9I?=
 =?iso-2022-jp?B?aFZGQ3Z3c1d3dlJXamRkaVZIZEk2cjkyQVVOb25vMzRMZmYzYUVNQThL?=
 =?iso-2022-jp?B?QmFva2pSN2ZRWDZxL2MvdWxpeEV5VmswZUJyTFhLUFlOLzlmUnBoaTRk?=
 =?iso-2022-jp?B?NDNKaTM5UjhpaEhIZWpVZ0lBc2FRdmd4THBNRjNGdGw2SWw1TUZLY2E1?=
 =?iso-2022-jp?B?RjRmQlZWdXYrelFDdWpadVhycE1jNmdlMGhzcWFIZzdwNVlZMjhFSlQ2?=
 =?iso-2022-jp?B?UkoyT083MnZsbXRMcG9jTElGcWg3dEpSRG15RjNLVnphSUxkdVNrdFBq?=
 =?iso-2022-jp?B?ZTdBcUNJOERZc3FFTWJ1QlJ3VzFIbmo3RVFEMDVjaFRnU3pocW02Nmp2?=
 =?iso-2022-jp?B?dFBRaXk3aGtSMkdzK0doZmt1TUJLQmdWelR2Q1RVbUxaaFMvcTBKb1Mv?=
 =?iso-2022-jp?B?NzhYVHVOUFZod2E3VmtJRGZUaEFPZkZoM1Q2R1hnZy9hakNiV3o0aVow?=
 =?iso-2022-jp?B?QVF5V0UrK2gxWERCaktRTjl6WVg3UWREVHhhZzVROTEyYlpYQkY2WnV5?=
 =?iso-2022-jp?B?Uk9mQnZNYXVPTE52YWlNK25LaHJVPQ==?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: fujitsu.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB4600.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fb9bc903-8228-4ad6-7bc1-08d979b1b75b
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2021 08:04:04.1244
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a19f121d-81e1-4858-a9d8-736e267fd4c7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vU2/bhUv0tzf04+W/z2hM2bZ7qgEIOxFUSxIu5SpJpV4doOa10zaUXkNg4FHbhpI+W7PBIGyQWcePMgCXSgFlJeIUazA2iHmfgApMSgZg8Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2040
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi, Ian=0A=
=0A=
> > On Tue, Aug 24, 2021 at 5:12 AM nakamura.shun@fujitsu.com=0A=
> > <nakamura.shun@fujitsu.com> wrote:=0A=
> > >=0A=
> > > Hi, Rob=0A=
> > >=0A=
> > > > On Fri, Aug 20, 2021 at 06:39:06PM +0900, Shunsuke Nakamura wrote:=
=0A=
> > > > > perf_evsel__read() scales counters obtained by RDPMC during multi=
plexing, but=0A=
> > > > > does not scale counters obtained by read() system call.=0A=
> > > > >=0A=
> > > > > Add processing to perf_evsel__read() to scale the counters obtain=
ed during the=0A=
> > > > > read() system call when multiplexing.=0A=
> > > >=0A=
> > > > Which one is right though? Changing what read() returns could break=
=0A=
> > > > users, right? Or are you implying that the RDPMC path is correct an=
d=0A=
> > > > read() was not. More likely the former case since I wrote the latte=
r.=0A=
> > >=0A=
> > > perf_evsel__read() returns both the count obtained by RDPMC and the c=
ount obtained=0A=
> > > by the read() system call when multiplexed with RDPMC enabled.=0A=
> > >=0A=
> > > That is, there is a mix of scaled and unscaled values.=0A=
> > >=0A=
> > > As Rob says, when this patch is applied, rescaling the count obtained=
 from=0A=
> > > perf_evsel__read() during multiplexing will break the count.=0A=
> > >=0A=
> > > I think the easiest solution is to change the value you get from RDPM=
C to not scale=0A=
> > > and let the user scale it, but I thought it would be a little inconve=
nient.=0A=
> >=0A=
> > Agreed, unless someone else has an opinion. It would be good to do the=
=0A=
> > scaling in libperf with the optimized math op, but I assume there's=0A=
> > some reason the user may need unscaled values?=0A=
> =0A=
> Hi, something I've mentioned on other threads [1] is that running may=0A=
> be zero due to multiplexing but enabled be greater. =0A=
=0A=
Thanks for your comment.=0A=
I'll fix it.=0A=
=0A=
> This can lead to a divide by zero when scaling. Giving the ratio to the c=
aller=0A=
> gives more information - I may be misunderstanding this thread, apologies=
 if so.=0A=
=0A=
The perf_counts_values contains enabled and running.=0A=
So, caller can calculate the ratio.=0A=
=0A=
Best Regards=0A=
Shunsuke=