Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <159de73b-fdd6-6df8-4f77-73c628fe641f@huawei.com>
 <a24634f7-be80-6ca2-9df7-1624fe11c281@arm.com> <c291692c-7db8-b4cc-e17a-422c75ad8daa@huawei.com>
In-Reply-To: <c291692c-7db8-b4cc-e17a-422c75ad8daa@huawei.com>
From:   Namhyung Kim <namhyung@kernel.org>
Date:   Mon, 12 Jun 2023 22:50:05 -0700
Message-ID: <CAM9d7chqy-RztC943JOgRLcEHvKZN8rS542q3xxW63==KGY3CQ@mail.gmail.com>
Subject: Re: [RFC] Adding support for setting the affinity of the recording process
To:     Yang Jihong <yangjihong1@huawei.com>
Cc:     James Clark <james.clark@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
        Adrian Hunter <adrian.hunter@intel.com>,
        linux-perf-users <linux-perf-users@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

Hello,

On Mon, Jun 12, 2023 at 7:28 PM Yang Jihong <yangjihong1@huawei.com> 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.

>
> >
> >> 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.

Thanks,
Namhyung