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

[Yang Jihong <yangjihong1@huawei.com>]

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.