Create source symlink in perf object dir
PATCH v10 1/4 Create source symlink in perf object dir
Create a source symlink to the original source in the objdir. This is similar to what the main kernel build script does.
--- tools/perf/Makefile.perf | 2 ++ 1 file changed, 2 insertions(+)
tools/perf/Makefile.perf +2 -0
@@ -163,6 +163,8 @@ ifneq ($(OUTPUT),) # for flex/bison parsers. VPATH += $(OUTPUT) export VPATH +# create symlink to the original source +SOURCE := $(shell ln -sf $(srctree)/tools/perf $(OUTPUT)/source) endif ifeq ($(V),1)
Signature · 1 line
2.45.2
PATCH v10 2/4 perf test: Support external tests for separate objdir
Extend the searching for the test files so that it works when running perf from a separate objdir, and also when the perf executable is symlinked.
----
v2: Fix string test (Namhyung)
Handle both in source and out of source builds.
v3: Remove duplicated string check (Namhyung)
--- tools/perf/tests/tests-scripts.c | 35 +++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-)
tools/perf/tests/tests-scripts.c +32 -3
@@ -29,16 +29,45 @@static int shell_tests__dir_fd (void ) { -char path[PATH_MAX ], *exec_path; -static const char *const devel_dirs[] = {"./tools/perf/tests/shell" ,"./tests/shell" , }; +struct stat st; +char path[PATH_MAX ], path2[PATH_MAX ], *exec_path; +static const char *const devel_dirs[] = { +"./tools/perf/tests/shell" , +"./tests/shell" , +"./source/tests/shell" + }; +int fd; +char *p;for (size_t i =0 ; i <ARRAY_SIZE (devel_dirs); ++i) { -int fd =open (devel_dirs[i],O_PATH ); + fd =open (devel_dirs[i],O_PATH );if (fd >=0 )return fd; } +/* Use directory of executable */ +if (readlink ("/proc/self/exe" , path2,sizeof path2) <0 ) +return -1 ; +/* Follow another level of symlink if there */ +if (lstat (path2, &st) ==0 && (st.st_mode &S_IFMT ) ==S_IFLNK ) { +scnprintf (path,sizeof (path), path2); +if (readlink (path, path2,sizeof path2) <0 ) +return -1 ; + } +/* Get directory */ + p =strrchr (path2,'/' ); +if (p) + *p =0 ; +scnprintf (path,sizeof (path),"%s/tests/shell" , path2); + fd =open (path,O_PATH ); +if (fd >=0 ) +return fd; +scnprintf (path,sizeof (path),"%s/source/tests/shell" , path2); + fd =open (path,O_PATH ); +if (fd >=0 ) +return fd; +/* Then installed path. */ exec_path =get_argv_exec_path ();scnprintf (path,sizeof (path),"%s/tests/shell" , exec_path);
Signature · 1 line
2.45.2
PATCH v10 3/4 perf script: Fix perf script -F +metric
In reply to Andi KleenThis fixes a regression with perf script -F +metric originally caused by :
commit 37cc8ad77cf81f3ffd226856c367b0e15333a738
Author: Ian Rogers <[email protected]> Date: Sun Feb 19 01:28:46 2023 -0800
perf metric: Directly use counts rather than saved_value
In the perf script environment the evsel wouldn't allocate an aggr values array, which led to a -1 reference because the metric evaluation would try to reference NULL - 1 (for aggr_idx)
Give the perf script evsels a single CPU aggr setup. That's enough because the groups are always contiguous, so no need to store more than one CPU's worth of values.
Before
% perf record -e '{cycles,instructions}:S' perf bench mem memcpy % perf script -F +metric
Segmentation fault (core dumped)
After:
% perf record -e '{cycles,instructions}:S' perf bench mem memcpy
...
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.028 MB perf.data (90 samples) ] % perf script -F +metric
perf-exec 1847557 264658.180789: 3009 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf-exec 1847557 264658.180789: 382 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf-exec 1847557 264658.180789: metric: 0.13 insn per cycle...
----
v2: Reformat code
v3: Work around bogus warning
v4: Set up aggr map only for metrics case to keep perf stat record working
v5: Broken version
v6: Only set up limited aggregation mode with -F +metric. Add conflict checks with perf stat record files.
v7: Remove some unnecessary conflict checks. Fix buffer overflow. Minor cleanups.
v8: Add check for leader sampling. Update some comments.
v9: Correct check for leader sampling (Namhyung)
v10: Check for PERF_FORMAT_GROUP and PERF_SAMPLE_READ (Namhyung)
v11: Use define for dummy aggregation index and add argument comments (Ian)
--- tools/perf/builtin-script.c | 61 ++++++++++++++++++++++++++++++++----- 1 file changed, 53 insertions(+), 8 deletions(-)
tools/perf/builtin-script.c +53 -8
@@ -335,10 +335,12 @@ struct evsel_script {FILE *fp;u64 samples;/* For metric output */ -u64 val;int gnum; }; +/* Use dummy index because no aggregation needed. */ +#define METRIC_AGGR_IDX 0 +static inline struct evsel_script *evsel_script (struct evsel *evsel) {return (struct evsel_script *)evsel->priv;
@@ -2127,20 +2129,34 @@ static void perf_sample__fprint_metric(struct perf_script *script, };struct evsel *ev2;u64 val; +static int printed;if (!evsel->stats)evlist__alloc_stats (&stat_config, script->session->evlist,/*alloc_raw=*/ false);if (evsel_script (leader)->gnum++ ==0 )perf_stat__reset_shadow_stats (); - val = sample->period * evsel->scale; -evsel_script (evsel)->val = val; + val = sample->period; +if (!(leader->core.attr.read_format &PERF_FORMAT_GROUP ) || + !(leader->core.attr.sample_type &PERF_SAMPLE_READ )) { +if (!printed) +fprintf (stderr,"perf script: -F metric requires {}:S for groups leader sampling\n" ); + printed =1 ; +return ; + } +/* +* Always use the first entry as storage (METRIC_AGGR_IDX) +* because the leader sampling groups are contiguous and +* there's no need to handle multiple indexes for anything. +*/ + evsel->stats->aggr[METRIC_AGGR_IDX ].counts.val = val;if (evsel_script (leader)->gnum == leader->core.nr_members) { for_each_group_member (ev2, leader) { -perf_stat__print_shadow_stats (&stat_config, ev2, -evsel_script (ev2)->val, - sample->cpu, - &ctx, -NULL ); +perf_stat__print_shadow_stats (/*config=*/ &stat_config, +/*evsel=*/ ev2, +/*avg=*/ evsel->stats->aggr[METRIC_AGGR_IDX ].counts.val, +/*aggr_idx=*/ METRIC_AGGR_IDX , +/*out=*/ &ctx, +/*metric_events=*/ NULL ); }evsel_script (leader)->gnum =0 ; }
@@ -2325,6 +2341,20 @@ static void process_event(struct perf_script *script,fflush (fp); } +static void check_metric_conflict (void ) +{ +int i; +/* +* Avoid conflict with the aggregation mode used for the metric printing. +*/ +for (i =0 ; i <OUTPUT_TYPE_MAX ; i++) { +if (output[i].fields &PERF_OUTPUT_METRIC ) { +fprintf (stderr,"perf stat record files are not supported with -F metric\n" ); +exit (1 ); + } + } +} +static struct scripting_ops *scripting_ops;static void __process_stat (struct evsel *counter,u64 tstamp)
@@ -2334,6 +2364,8 @@ static void __process_stat(struct evsel *counter, u64 tstamp)struct perf_cpu cpu;static int header_printed; +check_metric_conflict (); +if (!header_printed) {printf ("%3s %8s %15s %15s %15s %15s %s\n" ,"CPU" ,"THREAD" ,"VAL" ,"ENA" ,"RUN" ,"TIME" ,"EVENT" );
@@ -3725,6 +3757,8 @@ static int process_stat_config_event(struct perf_session *session __maybe_unused {perf_event__read_stat_config (&stat_config, &event->stat_config); +check_metric_conflict (); +/* * Aggregation modes are not used since post-processing scripts are * supposed to take care of such requirements
@@ -4088,6 +4122,17 @@ int cmd_script(int argc, const char **argv) argc =parse_options_subcommand (argc, argv, options, script_subcommands, script_usage,PARSE_OPT_STOP_AT_NON_OPTION ); +for (i =0 ; i <OUTPUT_TYPE_MAX ; i++) { +if (output[i].fields &PERF_OUTPUT_METRIC ) { + stat_config.aggr_map =cpu_aggr_map__empty_new (1 ); + err = -ENOMEM ; +if (!stat_config.aggr_map) + goto out; + err =0 ; + stat_config.aggr_map->nr =1 ; +break ; + } + } if (symbol_conf.guestmount || symbol_conf.default_guest_vmlinux_name ||
Signature · 1 line
2.45.2
PATCH v10 4/4 Add a test case for perf script -F +metric
In reply to Andi KleenSample a noploop workload with cycles and instructions and check if there is at least one metric being output by perf script.
The output is
% perf test -v 98
98: perf script tests
...
script metric test
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.429 MB /tmp/perf-test-script.nkvvuzMOla/perf.data (8174 samples) ]
perf-exec 853636 3967843.162782: metric: 0.15 insn per cycle
perf 853636 3967843.163210: metric: 0.87 insn per cycle
perf 853636 3967843.163226: metric: 0.84 insn per cycle
perf 853636 3967843.163240: metric: 0.88 insn per cycle
perf 853636 3967843.163276: metric: 1.06 insn per cycle
perf 853636 3967843.163387: metric: 1.09 insn per cycle
perf 853636 3967843.163578: metric: 1.17 insn per cycle
perf 853636 3967843.164412: metric: 4.53 insn per cycle
perf 853636 3967843.164623: metric: 1.18 insn per cycle
perf 853636 3967843.164817: metric: 1.25 insn per cyclescript metric test [Success]
...
%
----
v2: Avoid bashisms. Use noploop
v3: Avoid false positive in shellcheck
v4: Use :S in the test (Ian, Namhyung)
v5: Update commit message.
--- tools/perf/tests/shell/script.sh | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
tools/perf/tests/shell/script.sh +14 -0
@@ -7,6 +7,7 @@ set -e temp_dir=$(mktemp -d /tmp/perf-test-script.XXXXXXXXXX) perfdatafile="${temp_dir}/perf.data" +scriptoutput="${temp_dir}/script" db_test="${temp_dir}/db_test.py" err=0
@@ -88,8 +89,21 @@ test_parallel_perf() echo "parallel-perf test [Success]" } +test_metric() +{ + echo "script metric test" + if ! perf list | grep -q cycles ; then return ; fi + if ! perf list | grep -q instructions ; then return ; fi + perf record -e '{cycles,instructions}:S' -o "${perfdatafile}" perf test -w noploop + perf script -i "${perfdatafile}" -F +metric > $scriptoutput + test "`grep -c metric $scriptoutput`" -gt 5 + grep metric $scriptoutput | head + echo "script metric test [Success]" +} + test_db test_parallel_perf +test_metric cleanup
Signature · 1 line
2.45.2
Arnaldo,
can you please apply the patchkit? This fixes a regression.
-Andi
Arnaldo Carvalho de Melo
maintainerQuoted 3 lines · Andi Kleen
Arnaldo,
can you please apply the patchkit? This fixes a regression.
First one was applied, was letting the others to be out there for a while, I thought there were concerns about it, but I see Namhyung's Ack, so applied.
- Arnaldo
Ian Rogers
reviewerQuoted 9 lines · Arnaldo Carvalho de Melo
Quoted 3 lines · Andi Kleen
Arnaldo,
can you please apply the patchkit? This fixes a regression.
First one was applied, was letting the others to be out there for a while, I thought there were concerns about it, but I see Namhyung's Ack, so applied.
Can we not apply this? See comments on the thread. Basically we're committing to supporting hard coded metrics, aggregation and unusual period patterns in a way specifically for this feature and as attested by its brokenness nobody cares. The test ensures the feature can't go away. The feature should go away.
Thanks,
Ian
Arnaldo Carvalho de Melo
maintainerQuoted 6 lines · Ian Rogers
Quoted 4 lines · Arnaldo Carvalho de Melo
Quoted 1 line · Andi Kleen
Arnaldo,
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
can you please apply the patchkit? This fixes a regression.
First one was applied, was letting the others to be out there for a while, I thought there were concerns about it, but I see Namhyung's Ack, so applied.
Can we not apply this? See comments on the thread. Basically we're
And what about the reported segfault?
- Arnaldo
Ian Rogers
reviewerQuoted 10 lines · Arnaldo Carvalho de Melo
Quoted 8 lines · Ian Rogers
Quoted 6 lines · Arnaldo Carvalho de Melo
Quoted 3 lines · Andi Kleen
Arnaldo,
can you please apply the patchkit? This fixes a regression.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
First one was applied, was letting the others to be out there for a while, I thought there were concerns about it, but I see Namhyung's Ack, so applied.
Can we not apply this? See comments on the thread. Basically we're
And what about the reported segfault?
It is better addressed by:
https://lore.kernel.org/lkml/[email protected]/
One option though is to just remove this formatter. It is possible to change my patch to add the thread map support. I think also we should change perf script to not inject leader sample events similar to what was done for perf inject. This may break scripts, the scripts may already have been broken by the event injection. The change to perf script actively increases tech debt and aside from comments I see no difference in this series from the first that I objected to and set about trying to show how to fix the problem more properly.
Thanks,
Ian
Quoted 15 lines · Ian Rogers
Quoted 14 lines · Arnaldo Carvalho de Melo
Quoted 12 lines · Ian Rogers
Quoted 9 lines · Arnaldo Carvalho de Melo
Quoted 3 lines · Andi Kleen
Arnaldo,
can you please apply the patchkit? This fixes a regression.
First one was applied, was letting the others to be out there for a while, I thought there were concerns about it, but I see Namhyung's Ack, so applied.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Can we not apply this? See comments on the thread. Basically we're
And what about the reported segfault?
It is better addressed by:
https://lore.kernel.org/lkml/[email protected]/
I finally got around to test this other patch.
The reason for the feature is to get the metric for every individual sampling interval as the most fine grained unit, as it was explained in the original commit message:
perf script: Allow computing 'perf stat' style metrics
Add support for computing 'perf stat' style metrics in 'perf script'.
When using leader sampling we can get metrics ____for each sampling period___ by computing formulas over the values of the different group members.
This allows things like fine grained IPC tracking through sampling, much more fine grained than with 'perf stat'.
The metric is still averaged over the sampling period, it is not just for the sampling point.
...
Note the "for each sampling period" which is the key aspect.
With my version I get:
perf record -e '{cycles,instructions}:S' -a tcall
perf script -F +metric
perf 2061404 [000] 6395040.804752: 2687 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [000] 6395040.804752: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [000] 6395040.804752: metric: 0.15 insn per cycle
perf 2061404 [001] 6395040.804879: 2411 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [001] 6395040.804879: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [001] 6395040.804879: metric: 0.16 insn per cycle
perf 2061404 [002] 6395040.805000: 2245 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [002] 6395040.805000: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [002] 6395040.805000: metric: 0.18 insn per cycle
perf 2061404 [003] 6395040.805122: 2442 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [003] 6395040.805122: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [003] 6395040.805122: metric: 0.16 insn per cycle
perf 2061404 [004] 6395040.805241: 2208 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [004] 6395040.805241: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [004] 6395040.805241: metric: 0.18 insn per cycle
perf 2061404 [005] 6395040.805359: 2199 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [005] 6395040.805359: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [005] 6395040.805359: metric: 0.18 insn per cycle
perf 2061404 [006] 6395040.805479: 2269 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [006] 6395040.805479: 382 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [006] 6395040.805479: metric: 0.17 insn per cycle
perf 2061404 [007] 6395040.805596: 2215 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [007] 6395040.805596: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [007] 6395040.805596: metric: 0.18 insn per cycle
perf 2061404 [008] 6395040.805715: 2258 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [008] 6395040.805715: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [008] 6395040.805715: metric: 0.18 insn per cycle
perf 2061404 [009] 6395040.805835: 2293 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [009] 6395040.805835: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])You see there is one metric for every sampling period
But Ian's version generates this:
perf 2061404 [000] 6395040.804752: 2687 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [000] 6395040.804752: metric: 0.15 insn per cycle
perf 2061404 [000] 6395040.804752: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [000] 6395040.804752: metric: 0.07 insn per cycleThis is the only metric for "perf"
perf 2061404 [001] 6395040.804879: 2411 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [001] 6395040.804879: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [002] 6395040.805000: 2245 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [002] 6395040.805000: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [003] 6395040.805122: 2442 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [003] 6395040.805122: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [004] 6395040.805241: 2208 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [004] 6395040.805241: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [005] 6395040.805359: 2199 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [005] 6395040.805359: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [006] 6395040.805479: 2269 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [006] 6395040.805479: 382 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [007] 6395040.805596: 2215 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [007] 6395040.805596: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [008] 6395040.805715: 2258 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [008] 6395040.805715: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [009] 6395040.805835: 2293 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [009] 6395040.805835: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [010] 6395040.806013: 2159 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [010] 6395040.806013: 396 instructions: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms])
perf 2061404 [011] 6395040.806121: 3058 cycles: ffffffff990a579a native_write_msr+0xa ([kernel.kallsyms]).... <lots more samples but no metrics for "perf" anymore">
There are some metrics for other processes, but I don't even know what logic it follows here (as in what intervals actually get aggregated)
So yes maybe his implementation may be cleaner, but it simply doesn't solve the problem, it implements something else.
-Andi