Re: [RFC] Adding support for setting the affinity of the recording process

[Yang Jihong]

Hello,

On 2023/6/13 13:50, Namhyung Kim wrote:
> Hello,
>
> On Mon, Jun 12, 2023 at 7:28 PM Yang Jihong <yangjihong1@xxxxxxxxxx> wrote:
> > Hello,
> >
> > On 2023/6/12 23:27, James Clark wrote:
> > > On 12/06/2023 11:26, Yang Jihong wrote:
> > > > 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:
> > > >
> > > > 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
> > >
> > > I'm not sure if this is necessary. You can already do this with taskset
> > > when you launch the processes or for existing ones.
> >
> > Yes, that's what we're doing now, and I'm thinking about whether perf
> > can support this "taskset" feature.
>
> I agree with James that it looks out of scope of perf tools.
> You can always use `taskset` for external processes.
OK, so let's not consider this scenario.
> > > > 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.
> > > >
> > > >
> > > > Will we consider accepting this approach?
> > >
> > > For #2 I do this sometimes, but I prefix the perf command with taskset
> > > because otherwise there is a small time between when taskset does its
> > > thing and launching the child process that it runs in the wrong place.
> > >
> > > Then one issue with the above method is that perf itself gets pinned to
> > > those CPUs as well. I suppose that could influence your application but
> > > I've never had an issue with it.
> > >
> > > If you really can't live with perf also being pinned to those CPUs I
> > > would say it makes sense to add options for #2. Otherwise I would just
> > > run everything under taskset and no changes are needed.
> >
> > If "perf" process and the target process are pinned to the same CPU,
> > and the CPU usage of the target process is high, the perf data
> > collection may be affected. Therefore, in this case, we may need to pin
> > the target process and "perf" to different CPUs.
> >
> > > I think you would still need to have perf itself pinned to the CPUs just
> > > before it does the fork and exec, and then after that it can undo its
> > > pinning. Otherwise you'd still get that small time running on the wrong
> > > cores.
> >
> > Thanks for your advice, or we can support setting different affinities
> > for the "perf" process and the target process.
>
> When it comes to controlling `perf`, you can use --threads=<spec>
> option which supports fairly complex control for parallelism and
> affinity.
Yes, we can ues --threads=<spec>

In addition to the above, or we can simply add a parameter to pin the 
COMMAND to specific cpus.

Thank you for your reply.

Thanks,
Yang.