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;
Subject: Re: [RFC] Adding support for setting the affinity of the recording
 process
To:     Namhyung Kim <namhyung@kernel.org>
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>
References: <159de73b-fdd6-6df8-4f77-73c628fe641f@huawei.com>
 <a24634f7-be80-6ca2-9df7-1624fe11c281@arm.com>
 <c291692c-7db8-b4cc-e17a-422c75ad8daa@huawei.com>
 <CAM9d7chqy-RztC943JOgRLcEHvKZN8rS542q3xxW63==KGY3CQ@mail.gmail.com>
From:   Yang Jihong <yangjihong1@huawei.com>
Message-ID: <c2f82ca1-8fda-bd0c-4162-3a9e5d867a75@huawei.com>
Date:   Tue, 13 Jun 2023 15:03:58 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <CAM9d7chqy-RztC943JOgRLcEHvKZN8rS542q3xxW63==KGY3CQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hello,

On 2023/6/13 13:50, Namhyung Kim wrote:
> 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.
> 
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.