[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZIcqmlHIfBbyZFDl@kernel.org>
Date: Mon, 12 Jun 2023 11:24:26 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Yang Jihong <yangjihong1@...wei.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
linux-perf-users <linux-perf-users@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Adding support for setting the affinity of the recording
process
Em Mon, Jun 12, 2023 at 06:26:10PM +0800, Yang Jihong escreveu:
> Hello everyone,
>
> Currently, perf-record supports profiling an existing process, thread, or a
> specified command.
>
> Sometimes we may need to set CPU affinity of the target process before
> recording:
>
> # taskset -pc <cpus> <pid>
> # perf record -p <pid> -- sleep 10
>
> or:
>
> # perf record -- `taskset -c <cpus> COMMAND`
>
> I'm thinking about getting perf to support setting the affinity of the
> recording process, for example:
not of the 'recording process' but the 'observed process', right?
> 1. set the CPU affinity of the <pid1> process to <cpus1>, <pid2> process to
> <cpus2>, and record:
>
> # perf record -p <pid1>/<cpus1>:<pid2>/<cpus2> -- sleep 10
but what would be the semantic for what is being observed? Would this
result in it recording events on that CPU or just for that process (that
now runs just on that CPU)?
Without affinity setting that could mean: observe just that process when
it runs on that CPU.
But could you please spell out the use case, why do you need this, is
this so common (for you) that you repeatedly need to first taskset, then
perf, etc?
> and
>
> 2. set CPU affinity of the COMMAND and record:
>
> # perf record --taskset-command <cpus> COMMAND
>
> In doing so, perf, as an observer, actually changes some of the properties
> of the target process, which may be contrary to the purpose of perf tool.
Up for discussion, but I don't think this is that much a problem if it
streamlines common observability sessions/experimentations.
> Will we consider accepting this approach?
- Arnaldo
Powered by blists - more mailing lists