Message-ID: <73c70244-8dd8-4a5d-a132-1074e6205d37@bytedance.com>
Date: Thu, 5 Dec 2024 22:01:10 +0800
From: Yang Jihong <yangjihong@...edance.com>
To: Ian Rogers <irogers@...gle.com>, Namhyung Kim <namhyung@...nel.org>,
 Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: peterz@...radead.org, mingo@...hat.com, mark.rutland@....com,
 alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
 adrian.hunter@...el.com, kan.liang@...ux.intel.com, james.clark@....com,
 linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [RFC 00/12] perf record: Add event action support

Hello,

On 12/5/24 03:54, Ian Rogers wrote:
> On Wed, Dec 4, 2024 at 12:35 AM Yang Jihong <yangjihong@...edance.com> wrote:
>>
>> Hello,
>>
>> On 12/3/24 05:46, Namhyung Kim wrote:
>>> Hello,
>>>
>>> On Thu, Nov 28, 2024 at 05:14:53PM -0300, Arnaldo Carvalho de Melo wrote:
>>>> On Thu, Nov 28, 2024 at 09:35:41PM +0800, Yang Jihong wrote:
>>>>> In perf-record, when an event is triggered, default behavior is to
>>>>> save sample data to perf.data. Sometimes, we may just want to do
>>>>> some lightweight actions, such as printing a log.
>>>>
>>>>> Based on this requirement, add the --action option to the event to
>>>>> specify the behavior when the event occurs.
>>>>
>>>> 'perf record' is centered on saving data to disk without processing
>>>> events, while it has sideband events for some needs, like processing BPF
>>>> related events (PERF_RECORD_BPF_EVENT to catch PERF_BPF_EVENT_PROG_LOAD
>>>> and UNLOAD), doing things in a "live" way as your patchkit does seems
>>>> more appropriate to do in 'perf trace' :-)
>>>
>>> Agreed, 'perf trace' looks like a better place as you seem to target
>>> tracepoint events mostly.
>>>
>> Okay, will do it in 'perf trace'.
>>
>> Attaching to a kprobe events will also be supported in the future.
> 
> Hi Yang,
> 
> Just some extra information in case it is useful on python scripting,
> which could be reused to avoid writing a new interpreter as in this
> series. There are quite a few perf script examples here:

Thanks for your suggestion. I think using python scripting, similar to 
bcc, is more suitable for scenarios with complex requirements.
For some simple and lightweight scenarios, such as just printing some 
information in real time, one-line command (similar to dtrace)may be 
more suitable to implement user-defined sample.
This is just my idea, hope to discuss to improve the usability of 
perf-tool. :-)

> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/scripts/python?h=perf-tools-next
> There are also standalone scripts here including for tracepoints:
> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/python?h=perf-tools-next
> One of the things missing for standalone scripts was being able to
> conveniently parse events - you'd need to manually determine PMU type
> and config values. That is fixed in this reviewed but not merged
> series:
> https://lore.kernel.org/lkml/20241119011644.971342-1-irogers@google.com/
> 
> I'd like to see the python code improved as it allows quicker command
> creation like your example. Another example I'd recently tweaked is:
> https://lore.kernel.org/lkml/20241119180130.19160-1-irogers@google.com/
> Ultimately I think it would be nice to be creating tools using UIs
> like textualize:
> https://www.textualize.io/
> and our Gecko Google summer-of-code project was an improvement here:
> https://lore.kernel.org/lkml/ZOrsiZA+C0zbWEQS@yoga/
> 
> Other than basic functionality, perf's python support could be
> improved in a number of ways that we've discussed in office hours or
> on the list. Some things that come to mind:
> 1) The perf script callback mechanism doesn't feel particularly
> pythonic, generators or coroutines could be better.
> 2) We should probably have more library python code rather than adding
> new functions to `tools/perf/util/python.c` - I may do this to add
> type hints for mypy. If we could have a subset that works without the
> C code then it could be a basis for `perf.data` file analysis not tied
> to Linux, or `pip install`-able. There is a similar library with
> simpleperf, but shipping something with the perf codebase means we can
> keep the file format and library synchronized.
> 3) We'd like to reduce the number of dependencies `perf` as a command
> has, and libpython is a big one. Something `uftrace` did was dlopen
> libpython to avoid needing to link against it. A project similarly
> rethinking python binding with C code is HPy.
> 
Yes, we can greatly simplify the development work by using python.
In the end, if we can allow users to import perf python library and use 
a few simple codes to implement a customized data collection, it will be 
of great help to improve the usability of the perf tool.


Actually, I think perf-tool has a lot of functions and is very helpful 
for performance optimization, but the threshold is relatively high for 
beginners. (I don’t know if this is appropriate :-))

I have some considerations in improving the usability of the tool, but I 
don’t know if it is appropriate:
1. Provide rich prompt information, such as perf-help can provide some 
user requirements in an interactive way, provide common perf commands 
and usage methods; or provide some usage cases through keywords
2. Use some graphical interfaces as the backend so that users can use it 
in an easy-to-understand way
3. Based on the python you mentioned above, I think it is a good way to 
allow some developers to customize sampling data more easily.


Thanks,
Yang.

Powered by blists - more mailing lists