[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5a24632a-4293-3009-e4c6-e81d6ceb8f07@intel.com>
Date: Mon, 24 Jul 2023 20:51:15 +0300
From: Adrian Hunter <adrian.hunter@...el.com>
To: Changbin Du <changbin.du@...wei.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
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>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
Hui Wang <hw.huiwang@...wei.com>
Subject: Re: [PATCH v3 0/3] perf: add new option '--workload-attr' to set
workload sched_policy/priority/mask
On 24/07/23 12:34, Changbin Du wrote:
> On Mon, Jul 24, 2023 at 08:44:12AM +0300, Adrian Hunter wrote:
>> On 24/07/23 07:02, Changbin Du wrote:
>>> On Thu, Jul 20, 2023 at 01:00:58PM +0300, Adrian Hunter wrote:
>>>> On 18/07/23 06:33, Changbin Du wrote:
>>>>> This adds a new option '--workload-attr' to set the sched_policy/priority/mask
>>>>> of the workload to reduce system noise.
>>>>>
>>>>> $ sudo perf stat --workload-attr fifo,40,0-3:7 -- ls
>>>>
>>>> Not really sold on the need for this, but maybe it could be
>>>> simpler.
>>>> What about just adding a hook for a command (e.g. script) to
>>>> run before exec'ing the workload e.g.
>>>>
>>>> --configure-workload=blah.sh
>>>>
>>>> results in perf doing system("blah.sh 12345") where 12345
>>>> is the workload PID.
>>>>
>>>> Then maybe you could do:
>>>>
>>>> --configure-workload="taskset -p 0x3"
>>>>
>>> Acctually, we already have such option for perf-stat.
>>>
>>> --post <command> command to run after to the measured command
>>> --pre <command> command to run prior to the measured command
>>>
>>> By involving a shell script we can do more complex setup. But sometimes I just
>>> need to set sched attributes. For example, to investigate the impact of
>>> various compiler optimizations. In this case, I don't want a script. This is the
>>> original purpose I try to add this new option.
>>
>> There is also command schedtool, but what exactly is the problem
>> with a script?
>>
>>>
> There is no problem with a script, just a shortcut for convenience. When I want
> to share perf investigation with somebody, I just need to share a single commandline.
> Anyway nothing bad, right? :)
Also depends on what you call a single commandline, since you could
always create the script and run perf in one long line :-)
I would still go for the simpler option: easier to maintain and
potentially more flexible.
Powered by blists - more mailing lists