Received-SPF: pass (google.com: domain of linux-kernel+bounces-100962-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
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: AQHadNf1Lb9qvih3R0e9m3GYI58o8rE0yhJ9gAAEsmA=
Date: Wed, 13 Mar 2024 00:26:26 +0000
Message-ID: <CO6PR11MB56356A213DBE53535E9D802BEE2A2@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>
In-Reply-To: <87le6nm20o.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?9U4phJpFoUimZvn/ox5iCsWts5grEkHEq/2/ujaPpEmUYnmd1sAEHxoFi9WV?=
 =?us-ascii?Q?YJs2RS0vXoTCvfXv3z4YUYQNP+ux29RLyzhN25lvEJae0cheurBcKk/7i7ZC?=
 =?us-ascii?Q?9XrCaHDsz6HKKm0QJJp2eNSRS1Ws6yBrGV8yJoCRcMjJm2DNlKISH2LQWErn?=
 =?us-ascii?Q?USlLUAV9dEuuv9Cvr/rb1vvBSnD0RHhU5IycRhoYCnLulj4D2ftvWsesk4df?=
 =?us-ascii?Q?ktmllejavm5GqBMqUYT81210KbX3H0rZI3Mye0BWf4aP2QwDrjHyhde9u0j1?=
 =?us-ascii?Q?X+h9EzPCzIip8pkVh+6QUZwbZCdmKhhkL+1dKN8+BlnV32oPP5yprb4uRc0m?=
 =?us-ascii?Q?Z8kQyCor3pGDzilPLHIx1TC9dDVsG8IRDS5fK39DwMnH0iLSxH9ZDttK3M9G?=
 =?us-ascii?Q?HTtQpeywTQUQb9ATLxuuO4iO5MGF5tQWwldOyEb9KUig3TAu8YvdNMG8CIZy?=
 =?us-ascii?Q?DiAmcbWdf73xjkMjTIzi7oQfQuD7Tw8K4tgUHgoUNi47rK82TIludzlHTqZz?=
 =?us-ascii?Q?f5Gx6i1ETYsWkTP2ZM0GqkCvwI+9c9JFVZRYA6hrEIBWcoQXihw7IgllXkEA?=
 =?us-ascii?Q?R2u5Bye/nHl+pZKVATuacY78uINEVUm4XPRZaENXnFPbfdaMXfO/4x7Hde+T?=
 =?us-ascii?Q?MzbbSZ1m7JvSxaiYaS2OHNBgT57YRne98qWjXpi8Mr2WxWaWUsNzAvTUAwIl?=
 =?us-ascii?Q?yo247ov1KpXVdVv157ojpkWgjPZv7Glt+3p6wLaZymaNTgW6wqyx6YWkxcDZ?=
 =?us-ascii?Q?Z3MhCug2960/qUufW9NwceNbweA6swWsag8+xvzAmqzKRbfZW1USmmkjchvA?=
 =?us-ascii?Q?8H+U97M5g+wxQvutpTf2QnjBT36r34oqy2oP4PqE0P6e8PqvSBAyuymG3ZqQ?=
 =?us-ascii?Q?2S+DEHCY3OhT9jknsButLp/Xow3EYq0JR6LeuB2H7Sc7+NxlbR1AuVN3pLG9?=
 =?us-ascii?Q?Nv2r8DQKBUHlHqR5rpbSgUa8aPW4J4V92i5bFwxjFeV60QRb3zoj2vId/l70?=
 =?us-ascii?Q?JqSyZff/rWQzteUxnbnuhk4r06PQ52DGJXEBA6iYpU5JitjHqAqKOGJJE+eY?=
 =?us-ascii?Q?tv1TGt7KxvQQBnCGbkpqW+yRYYFaJ26ypKI+EX6S+4b9/GkL2nZVLzoQlsNj?=
 =?us-ascii?Q?jrxZ22Qk5CaUlpvr4jYIiB1TJSlYNpzC0bJtKxoglBX36HcmVDgkqekDen+U?=
 =?us-ascii?Q?1cTEaUIwJxtCVnU5Cd7qXRBtuREfvJr13yhDcWc+mlrK4JADEAYT0sXI8nqv?=
 =?us-ascii?Q?S3oLZo3oXJHe3+hU3VHh5JI5Inr65c1vyKzZNsd8U5Zu0ZrdNHq/L5FLbALY?=
 =?us-ascii?Q?AhJqCheUpU3jNL/crVT4K1sO9BZUoQQJTJ4qywamYTB9K3RbChDkv9aJLH3w?=
 =?us-ascii?Q?MlrrcYNE1oY6b3b+52ZrjgJacl0yUv6hxxrSpBlBgSVrT/O4MsiHqgRn21zo?=
 =?us-ascii?Q?XLlsX1tjV1qQGL8JByRbdeEJprFl7LKQVyIyh3WuIfREMEzE29LoUjOpIwwY?=
 =?us-ascii?Q?XgPuIdsLKBF5yDeUYnD73wKqUXgLHkA1L/T6nuOt24INt/fz+1aq6TaPmab/?=
 =?us-ascii?Q?aU2KqxTipfihIivuoW1Gao+cWnHzrGMChZjZ8056?=
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: f483f68e-a771-41d7-fc18-08dc42f43826
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2024 00:26:26.0960
 (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: eDFchQzV56oDB4nxIr+IOzD1XhIYyCCi0GIFqbOdXDHLsPeJYnZknPkvjMQnPBBW1j8alj+ia/ip8QoJyoUKPA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR11MB8755
X-OriginatorOrg: intel.com


> -----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 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
> weilin.wang@intel.com writes:
>=20
> > From: Weilin Wang <weilin.wang@intel.com>
> >
> > When retire_latency value is used in a metric formula, perf stat would =
fork a
> > perf record process with "-e" and "-W" options. Perf record will collec=
t
> > required retire_latency values in parallel while perf stat is collectin=
g
> > counting values.
>=20
> 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.
>=20
> The perf tool infrastructure is imho not up to the task of such
> parallel collection.
>=20
> Also it won't work for very long collections because you will get a
> very large perf.data. Better to use a pipeline.
>=20
> I think it would be better if you made it a separate operation that can
> generate a file that is then consumed by perf stat. This is also more eff=
icient
> because often the calibration is only needed once. And it's all under
> user control so no nasty surprises.
>=20

Workload runs only once with perf stat. Perf record is forked by perf stat =
and run
in parallel with perf stat. Perf stat will send perf record a signal to ter=
minate after=20
perf stat stops collecting count value.

The implementation uses a PIPE to pass the sampled data from perf record in=
stead
of writing the data into a file.

Thanks,
Weilin

> -Andi