[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/3] Add Scripts for Finding Top 25 Executed Functions
From: |
Alex Bennée |
Subject: |
Re: [PATCH 0/3] Add Scripts for Finding Top 25 Executed Functions |
Date: |
Wed, 17 Jun 2020 18:42:53 +0100 |
User-agent: |
mu4e 1.5.3; emacs 28.0.50 |
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com> writes:
> сре, 17. јун 2020. у 17:34 Alex Bennée <alex.bennee@linaro.org> је написао/ла:
>>
>>
>> Eric Blake <eblake@redhat.com> writes:
>>
>> > On 6/16/20 6:12 PM, Ahmed Karaman wrote:
>> >> Greetings,
>> >>
>> >> As a part of the TCG Continous Benchmarking project for GSoC this
>> >> year, detailed reports discussing different performance measurement
>> >> methodologies and analysis results will be sent here on the mailing
>> >> list.
>> >>
>> >> The project's first report is currently being revised and will be
>> >> posted on the mailing list in the next few days.
>> >> A section in this report will deal with measuring the top 25 executed
>> >> functions when running QEMU. It includes two Python scripts that
>> >> automatically perform this task.
>> >>
>> >> This series adds these two scripts to a new performance directory
>> >> created under the scripts directory. It also adds a new
>> >> "Miscellaneous" section to the end of the MAINTAINERS file with a
>> >> "Performance Tools and Tests" subsection.
>> >>
>> >> Best regards,
>> >> Ahmed Karaman
>> >>
>> >> Ahmed Karaman (3):
>> >> MAINTAINERS: Add 'Miscellaneous' section
>> >> scripts/performance: Add callgrind_top_25.py script
>> >> scripts/performance: Add perf_top_25.py script
>> >>
>> >> MAINTAINERS | 7 ++
>> >> scripts/performance/callgrind_top_25.py | 95 +++++++++++++++++++++++++
>> >> scripts/performance/perf_top_25.py | 82 +++++++++++++++++++++
>> >> 3 files changed, 184 insertions(+)
>> >> create mode 100644 scripts/performance/callgrind_top_25.py
>> >> create mode 100644 scripts/performance/perf_top_25.py
>> >
>> > Are the new scripts supposed to have executable permissions, or are they
>> > always invoked as 'python path/to/script.py' where the executable bit is
>> > less important?
>>
>> I would assume +x for directly invocable scripts - certainly we have a
>> lot of those in the scripts directory.
>>
>
> There is no reason IMHO for these scripts not having +x and Ahmed
> should correct this in v2, and I think that was his original
> intention.
>
> However, I was a little surprized though when I found out this in our
> scripts directory:
>
> $ find . -name \*.py -type f -print | xargs ls -l
<snip>
> -rw-r--r-- 1 rtrk rtrk 20723 May 10 11:21 ./dump-guest-memory.py
> -rw-r--r-- 1 rtrk rtrk 2751 Jun 2 10:22 ./modules/module_block.py
> -rw-r--r-- 1 rtrk rtrk 7842 May 10 11:21 ./qapi/commands.py
> -rw-r--r-- 1 rtrk rtrk 5673 May 10 11:21 ./qapi/common.py
> -rw-r--r-- 1 rtrk rtrk 9742 May 10 11:21 ./qapi/doc.py
> -rw-r--r-- 1 rtrk rtrk 1107 May 10 11:21 ./qapi/error.py
> -rw-r--r-- 1 rtrk rtrk 6148 May 10 11:21 ./qapi/events.py
> -rw-r--r-- 1 rtrk rtrk 12297 May 10 11:21 ./qapi/expr.py
> -rw-r--r-- 1 rtrk rtrk 8280 May 10 11:21 ./qapi/gen.py
> -rw-r--r-- 1 rtrk rtrk 0 May 10 11:21 ./qapi/__init__.py
> -rw-r--r-- 1 rtrk rtrk 8533 May 10 11:21 ./qapi/introspect.py
> -rw-r--r-- 1 rtrk rtrk 21696 May 10 11:21 ./qapi/parser.py
> -rw-r--r-- 1 rtrk rtrk 41301 May 10 11:21 ./qapi/schema.py
> -rw-r--r-- 1 rtrk rtrk 1789 May 10 11:21 ./qapi/source.py
> -rw-r--r-- 1 rtrk rtrk 8724 May 10 11:21 ./qapi/types.py
> -rw-r--r-- 1 rtrk rtrk 9980 May 10 11:21 ./qapi/visit.py
> -rw-r--r-- 1 rtrk rtrk 1843 Jun 2 10:22 ./qemugdb/aio.py
> -rw-r--r-- 1 rtrk rtrk 3514 Jun 2 10:22 ./qemugdb/coroutine.py
> -rw-r--r-- 1 rtrk rtrk 897 Jun 2 10:22 ./qemugdb/__init__.py
> -rw-r--r-- 1 rtrk rtrk 2741 Jun 2 10:22 ./qemugdb/mtree.py
> -rw-r--r-- 1 rtrk rtrk 1213 Jun 2 10:22 ./qemu-gdb.py
> -rw-r--r-- 1 rtrk rtrk 1469 Jun 2 10:22 ./qemugdb/tcg.py
> -rw-r--r-- 1 rtrk rtrk 1850 Jun 2 10:22 ./qemugdb/timers.py
> -rw-r--r-- 1 rtrk rtrk 2447 May 10 11:21 ./simplebench/bench-example.py
> -rw-r--r-- 1 rtrk rtrk 4615 May 10 11:21 ./simplebench/simplebench.py
> -rw-r--r-- 1 rtrk rtrk 1443 May 10 11:21 ./tracetool/backend/dtrace.py
> -rw-r--r-- 1 rtrk rtrk 1471 May 10 11:21 ./tracetool/backend/ftrace.py
> -rw-r--r-- 1 rtrk rtrk 4098 May 10 11:21 ./tracetool/backend/__init__.py
> -rw-r--r-- 1 rtrk rtrk 1499 May 10 11:21 ./tracetool/backend/log.py
> -rw-r--r-- 1 rtrk rtrk 3116 May 10 11:21 ./tracetool/backend/simple.py
> -rw-r--r-- 1 rtrk rtrk 1175 May 10 11:21 ./tracetool/backend/syslog.py
> -rw-r--r-- 1 rtrk rtrk 1190 May 10 11:21 ./tracetool/backend/ust.py
> -rw-r--r-- 1 rtrk rtrk 2094 May 10 11:21 ./tracetool/format/c.py
> -rw-r--r-- 1 rtrk rtrk 1744 May 10 11:21 ./tracetool/format/d.py
> -rw-r--r-- 1 rtrk rtrk 2912 May 10 11:21 ./tracetool/format/h.py
> -rw-r--r-- 1 rtrk rtrk 2402 May 10 11:21 ./tracetool/format/__init__.py
> -rw-r--r-- 1 rtrk rtrk 3725 May 10 11:21 ./tracetool/format/log_stap.py
> -rw-r--r-- 1 rtrk rtrk 2467 May 10 11:21
> ./tracetool/format/simpletrace_stap.py
> -rw-r--r-- 1 rtrk rtrk 1653 May 10 11:21 ./tracetool/format/stap.py
> -rw-r--r-- 1 rtrk rtrk 2388 May 10 11:21 ./tracetool/format/tcg_helper_c.py
> -rw-r--r-- 1 rtrk rtrk 1343 May 10 11:21 ./tracetool/format/tcg_helper_h.py
> -rw-r--r-- 1 rtrk rtrk 2145 May 10 11:21
> ./tracetool/format/tcg_helper_wrapper_h.py
> -rw-r--r-- 1 rtrk rtrk 2749 May 10 11:21 ./tracetool/format/tcg_h.py
> -rw-r--r-- 1 rtrk rtrk 968 May 10 11:21 ./tracetool/format/ust_events_c.py
> -rw-r--r-- 1 rtrk rtrk 3678 May 10 11:21 ./tracetool/format/ust_events_h.py
> -rw-r--r-- 1 rtrk rtrk 14489 May 10 11:21 ./tracetool/__init__.py
> -rw-r--r-- 1 rtrk rtrk 4301 May 10 11:21 ./tracetool/transform.py
> -rw-r--r-- 1 rtrk rtrk 2067 May 10 11:21 ./tracetool/vcpu.py
So I think these are all modules or loaded indirectly (in the case of
the gdb helpers). There was a big clean-up recently removing the
#!/bin/env python headers from a chunk of these.
<snip>
> -rw-r--r-- 1 rtrk rtrk 310 May 10 11:21 ./shaderinclude.pl
Arguably this could be +x but it seems to be there for the benefit of
the make system which explicitly calls perl anyway.
>
> Are all these permissions all right?
I think so.
--
Alex Bennée