Received-SPF: pass (google.com: domain of linux-kernel+bounces-101680-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: "Wang, Weilin" <weilin.wang@intel.com>
To: Andi Kleen <ak@linux.intel.com>
CC: Namhyung Kim <namhyung@kernel.org>, Ian Rogers <irogers@google.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>, Peter Zijlstra
	<peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Alexander Shishkin
	<alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, "Hunter,
 Adrian" <adrian.hunter@intel.com>, Kan Liang <kan.liang@linux.intel.com>,
	"linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Taylor,
 Perry" <perry.taylor@intel.com>, "Alt, Samantha" <samantha.alt@intel.com>,
	"Biggers, Caleb" <caleb.biggers@intel.com>
Subject: RE: [RFC PATCH v4 2/6] perf stat: Fork and launch perf record when
 perf stat needs to get retire latency value for a metric.
Thread-Topic: [RFC PATCH v4 2/6] perf stat: Fork and launch perf record when
 perf stat needs to get retire latency value for a metric.
Thread-Index: AQHadNf1Lb9qvih3R0e9m3GYI58o8rE0yhJ9gAAEsmCAAAoM2YAA8zyQ
Date: Wed, 13 Mar 2024 15:31:14 +0000
Message-ID: <CO6PR11MB56351D1706A9C46D80982AECEE2A2@CO6PR11MB5635.namprd11.prod.outlook.com>
References: <20240312234921.812685-1-weilin.wang@intel.com>
	<20240312234921.812685-3-weilin.wang@intel.com>
	<87le6nm20o.fsf@linux.intel.com>
	<CO6PR11MB56356A213DBE53535E9D802BEE2A2@CO6PR11MB5635.namprd11.prod.outlook.com>
 <87edcflzkr.fsf@linux.intel.com>
In-Reply-To: <87edcflzkr.fsf@linux.intel.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?slnxQbUo2m+B8pLCkh1Qwm7AOCLlZRUoWhiQOwVDa3MU39p1lEDVOTXVxgVs?=
 =?us-ascii?Q?0kBRvP0QPIUTDo4DRSa9H3jRLDkmel8pmWT8zxooKWWwZV6B4zs52JI6qDAp?=
 =?us-ascii?Q?zVyFIAMkBp6ZQn946dMmYRoXZJMuIgx74PwoZRlZDafsO2AETEC6a6Y97SsT?=
 =?us-ascii?Q?nqRqqNUN3JoM7AWLX+mdEQfxVndHfoUax9t3V07ZHsRAy8eLMGC8OnXthR/a?=
 =?us-ascii?Q?7sJ6zEKH57mydp2otn5znHNFClniLPDqTSKpD97Ca7qArnItv63uGj3VhBpJ?=
 =?us-ascii?Q?w5M71Ypu1sTM/BXz9fKZu3aMaZwueTZOxAFc2eouwGRhgN1EAnZiEFCb+fNO?=
 =?us-ascii?Q?yX/p45q4HZjJn88VnYE87wX7bS1PEdS76nC7+UWNUq2m8ltXz0HaqS4rBSVB?=
 =?us-ascii?Q?r1B0Cm1qSmxogsD6gZyUPtMdKUX3PZzbnQJ5RUWI2so95ZrJ/5ciS7M1HXo6?=
 =?us-ascii?Q?1BIWvVyQqjtyQhfDUMxIY+uyQBYOCHoHb/1wSr9Xo+BrbY1+NEeLSjHmsRxv?=
 =?us-ascii?Q?O71Cv7axdpjysRBQDd3Qppgrwa0zm9k+uwrkMXLTevwh5YpueX5P/mElqbHJ?=
 =?us-ascii?Q?6OGVCsNgJF8BRwtFR0IvdAUycG748x8UxouSCQgmi0yc0ByW9Re2G3Y4Ikw+?=
 =?us-ascii?Q?+Oqd0Ij9g0ufzxWriRj9EGPv40+4dt4Cy5pq9Z2/mrYUs7v1EKgMcLMGDZ0f?=
 =?us-ascii?Q?Ex3Xll+Pw8j+xBBMv0eYnu7yaSVsvmkGgE9mBnMIY5GMUO0DNHBsoOZ1WnUo?=
 =?us-ascii?Q?A6wxuSthf0tlrGxjViV5C3Kb2C1d/hP/TpxLSO8unph2/lQMUp3CTi4stdty?=
 =?us-ascii?Q?oK8sc0qPiBAiSX1MmxMfzmhQGs5WaWkKLfwDlGb2hs14kmVHX+GANJ9W3/F7?=
 =?us-ascii?Q?w7CuOeCqNwgR9AwfAyOdII2tSXPAQK50oWcC5f+9PQgW1TbpUBdxiNO2GZg4?=
 =?us-ascii?Q?Fpcq0GoXSo9pyTUGvmJrn59xf3rPiL2mIMsBHTvYtyd3rtkpbL2a30NjpV9x?=
 =?us-ascii?Q?K2fjndSMOco/ByMAUIS+ZyZrIk61qzxQZKY3Qm6EVc9K1DuSdEoOfVxQvAcF?=
 =?us-ascii?Q?3KsW2dcMUCz5LGOUrZL3XucZav40Ej6YSgRzI/V07DPqaRYs9R70KpDmucZo?=
 =?us-ascii?Q?Uf5rEHHtuRE/AjBmwSFqgLrqEYoK46ej3qoFi1HoAN/eCuWiCq+lCYbnC6O4?=
 =?us-ascii?Q?LOVWoGLzQahaIeNE2cj/ukgq4pNmEqT+3PHcTxLT5HkV1UrBujlCKrwJqEXG?=
 =?us-ascii?Q?HMUGVk8Vcv4wgZFz0KAanWf0CgfrDUNikZbN9DvNULaphdq7MMfidsFB8tfk?=
 =?us-ascii?Q?B6fcpJibinTo7FnWozQwWSBqD74XCV53ig1E/PejG+LFMZ6vxush9AGZYt1O?=
 =?us-ascii?Q?YPpIiUMJ/q1cDrR3U7wMbI6R16rCxn2aoCVAcS3yNwu7fDygu52Tg9QEURoX?=
 =?us-ascii?Q?DsoQhQ67SDhLdI6sOfhno/1fQCzjRo/dPg91WflJ7sStodhaiGiyyU1xR2d8?=
 =?us-ascii?Q?lVLQUESEQD+esArnUH1DjUAG5mi8AquDlra1Yd1gxv5ITF1r4w3ECnirfqSy?=
 =?us-ascii?Q?nftukh3K+a0qdzvwjLUmy2M1uoiztqjQyNgvlVz3?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5635.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 996f22b6-d296-48c5-080b-08dc43729e98
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2024 15:31:14.5716
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QAh6wgrHgoObUojPBogMN9sntoJEPh4J0pGtw6OyE4QytcI3mWpFJJYufmdajzkrBDZf4hZ2emGu/Mqv+r/NiA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7876
X-OriginatorOrg: intel.com


> -----Original Message-----
> From: Andi Kleen <ak@linux.intel.com>
> Sent: Tuesday, March 12, 2024 5:56 PM
> To: Wang, Weilin <weilin.wang@intel.com>
> Cc: Namhyung Kim <namhyung@kernel.org>; Ian Rogers
> <irogers@google.com>; Arnaldo Carvalho de Melo <acme@kernel.org>; Peter
> Zijlstra <peterz@infradead.org>; Ingo Molnar <mingo@redhat.com>;
> Alexander Shishkin <alexander.shishkin@linux.intel.com>; Jiri Olsa
> <jolsa@kernel.org>; Hunter, Adrian <adrian.hunter@intel.com>; Kan Liang
> <kan.liang@linux.intel.com>; linux-perf-users@vger.kernel.org; linux-
> kernel@vger.kernel.org; Taylor, Perry <perry.taylor@intel.com>; Alt, Sama=
ntha
> <samantha.alt@intel.com>; Biggers, Caleb <caleb.biggers@intel.com>
> Subject: Re: [RFC PATCH v4 2/6] perf stat: Fork and launch perf record wh=
en
> perf stat needs to get retire latency value for a metric.
>=20
> "Wang, Weilin" <weilin.wang@intel.com> writes:
>=20
> >> -----Original Message-----
> >> From: Andi Kleen <ak@linux.intel.com>
> >> Sent: Tuesday, March 12, 2024 5:03 PM
> >> To: Wang, Weilin <weilin.wang@intel.com>
> >> Cc: Namhyung Kim <namhyung@kernel.org>; Ian Rogers
> >> <irogers@google.com>; Arnaldo Carvalho de Melo <acme@kernel.org>;
> Peter
> >> Zijlstra <peterz@infradead.org>; Ingo Molnar <mingo@redhat.com>;
> >> Alexander Shishkin <alexander.shishkin@linux.intel.com>; Jiri Olsa
> >> <jolsa@kernel.org>; Hunter, Adrian <adrian.hunter@intel.com>; Kan Lian=
g
> >> <kan.liang@linux.intel.com>; linux-perf-users@vger.kernel.org; linux-
> >> kernel@vger.kernel.org; Taylor, Perry <perry.taylor@intel.com>; Alt,
> Samantha
> >> <samantha.alt@intel.com>; Biggers, Caleb <caleb.biggers@intel.com>
> >> Subject: Re: [RFC PATCH v4 2/6] perf stat: Fork and launch perf record
> when
> >> perf stat needs to get retire latency value for a metric.
> >>
> >> weilin.wang@intel.com writes:
> >>
> >> > From: Weilin Wang <weilin.wang@intel.com>
> >> >
> >> > When retire_latency value is used in a metric formula, perf stat wou=
ld fork
> a
> >> > perf record process with "-e" and "-W" options. Perf record will col=
lect
> >> > required retire_latency values in parallel while perf stat is collec=
ting
> >> > counting values.
> >>
> >> How does that work when the workload is specified on the command line?
> >> The workload would run twice? That is very inefficient and may not
> >> work if it's a large workload.
> >>
> >> The perf tool infrastructure is imho not up to the task of such
> >> parallel collection.
> >>
> >> Also it won't work for very long collections because you will get a
> >> very large perf.data. Better to use a pipeline.
> >>
> >> I think it would be better if you made it a separate operation that ca=
n
> >> generate a file that is then consumed by perf stat. This is also more =
efficient
> >> because often the calibration is only needed once. And it's all under
> >> user control so no nasty surprises.
> >>
> >
> > Workload runs only once with perf stat. Perf record is forked by perf s=
tat and
> run
> > in parallel with perf stat. Perf stat will send perf record a signal to=
 terminate
> after
> > perf stat stops collecting count value.
>=20
> I don't understand how the perf record filters on the workload created by
> the perf stat. At a minimum you would need -p to connect to the pid
> of the parent, but IIRC -p doesnt follow children, so if it forked
> it wouldn't work.
>=20
> I think your approach may only work with -a, but perhaps I'm missing
> something (-a is often not usable due to restrictions)
>=20
> Also if perf stat runs in interval mode and you only get the data
> at the end how would that work?
>=20
> iirc i wrestled with all these questions for toplev (which has a
> similar feature) and in the end i concluded doing it automatically
> has far too many problems.
>=20

Yes, you are completely right that there are limitation that we can only su=
pport -a, -C=20
and not support on -I now. I'm wondering if we could support "-I" in next s=
tep by=20
processing sampled data on the go.

Thanks,
Weilin

> -Andi