[PATCH] perf tools: Do not show trace command if it's not compiled in

[Jiri Olsa]

The trace command still appears in help message when you
run simple 'perf' command.

It's because the generate-cmdlist.sh does not care about the
HAVE_LIBAUDIT_SUPPORT dependency of trace command and puts
it into generated common_cmds array.

Wrapping trace command under HAVE_LIBAUDIT_SUPPORT dependency,
which will exclude it from common_cmds array if HAVE_LIBAUDIT_SUPPORT
is not set.

Link: http://lkml.kernel.org/n/tip-eys6x7vq4y...@git.kernel.org
Signed-off-by: Jiri Olsa <jo...@kernel.org>
---
tools/perf/command-list.txt | 2 +-
tools/perf/util/generate-cmdlist.sh | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/tools/perf/command-list.txt b/tools/perf/command-list.txt
index acc3ea7d90b7..ab5cbaa170d0 100644
--- a/tools/perf/command-list.txt
+++ b/tools/perf/command-list.txt
@@ -26,4 +26,4 @@ perf-stat mainporcelain common
perf-test mainporcelain common
perf-timechart mainporcelain common
perf-top mainporcelain common
-perf-trace mainporcelain common
+perf-trace mainporcelain audit
diff --git a/tools/perf/util/generate-cmdlist.sh b/tools/perf/util/generate-cmdlist.sh
index 36a885d2cd22..0ac2037c970c 100755
--- a/tools/perf/util/generate-cmdlist.sh
+++ b/tools/perf/util/generate-cmdlist.sh
@@ -36,4 +36,19 @@ do
}' "Documentation/perf-$cmd.txt"
done
echo "#endif /* HAVE_LIBELF_SUPPORT */"
+
+echo "#ifdef HAVE_LIBAUDIT_SUPPORT"
+sed -n -e 's/^perf-\([^ ]*\)[ ].* audit*/\1/p' command-list.txt |
+sort |
+while read cmd
+do
+ sed -n '
+ /^NAME/,/perf-'"$cmd"'/H
+ ${
+ x
+ s/.*perf-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
+ p
+ }' "Documentation/perf-$cmd.txt"
+done
+echo "#endif /* HAVE_LIBELF_SUPPORT */"
echo "};"
--
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Ingo Molnar]

* Jiri Olsa <jo...@kernel.org> wrote:

> The trace command still appears in help message when you
> run simple 'perf' command.
>
> It's because the generate-cmdlist.sh does not care about the
> HAVE_LIBAUDIT_SUPPORT dependency of trace command and puts
> it into generated common_cmds array.
>
> Wrapping trace command under HAVE_LIBAUDIT_SUPPORT dependency,
> which will exclude it from common_cmds array if HAVE_LIBAUDIT_SUPPORT
> is not set.

Btw., would it make sense to still list them, but denote them as '[NOT BUILT IN]':

The most commonly used perf commands are:
annotate Read perf.data (created by perf record) and display annotated code
archive Create archive with object files with build-ids found in perf.data file
bench General framework for benchmark suites
buildid-cache Manage build-id cache.
buildid-list List the buildids in a perf.data file
config Get and set variables in a configuration file.
data Data file related processing
diff Read perf.data files and display the differential profile
evlist List the event names in a perf.data file
inject Filter to augment the events stream with additional information
kmem Tool to trace/measure kernel memory properties
kvm Tool to trace/measure kvm guest os
list List all symbolic event types
lock Analyze lock events
mem Profile memory accesses
record Run a command and record its profile into perf.data
report Read perf.data (created by perf record) and display the profile
sched Tool to trace/measure scheduler properties (latencies)
script Read perf.data (created by perf record) and display trace output
stat Run a command and gather performance counter statistics
test Runs sanity tests.
timechart Tool to visualize total system behavior during a workload
top System profiling tool.
probe Define new dynamic tracepoints
trace [NOT BUILT IN] strace inspired tool

?

... and print something informative if someone tries to use it:

triton:~/tip> perf trace
Error: The 'trace' subcommand is not built into this version of perf.
Solution: You can enable it by rebuilding perf with all required libraries installed.

Instead of the rather misleading:

triton:~/tip> perf trace
perf: 'trace' is not a perf-command. See 'perf --help'.

(Plus once we grow a 'perf upgrade' command, we can suggest rebuilding via that
route.)

Thanks,

Ingo

[Arnaldo Carvalho de Melo]

Em Tue, Jan 12, 2016 at 12:23:41PM +0100, Ingo Molnar escreveu:
>
> * Jiri Olsa <jo...@kernel.org> wrote:
>
> > The trace command still appears in help message when you
> > run simple 'perf' command.
> >
> > It's because the generate-cmdlist.sh does not care about the
> > HAVE_LIBAUDIT_SUPPORT dependency of trace command and puts
> > it into generated common_cmds array.
> >
> > Wrapping trace command under HAVE_LIBAUDIT_SUPPORT dependency,
> > which will exclude it from common_cmds array if HAVE_LIBAUDIT_SUPPORT
> > is not set.
>
> Btw., would it make sense to still list them, but denote them as '[NOT BUILT IN]':

Yeah, just like we have:

$ make NO_DWARF=1 O=/tmp/build/perf -C tools/perf/ install
make: Entering directory '/home/git/linux/tools/perf'
BUILD: Doing 'make -j4' parallel build
config/Makefile:328: DWARF support is off, BPF prologue is disabled
SUBDIR Documentation
ASCIIDOC /tmp/build/perf/perf-diff.xml
CC /tmp/build/perf/util/abspath.o
<SNIP>

$ perf record -h vm build

Usage: perf record [<options>] [<command>]
or: perf record [<options>] -- <command> [<options>]

-B, --no-buildid do not collect buildids in perf.data
-N, --no-buildid-cache do not update the buildid cache
--vmlinux <file> vmlinux pathname
(not built-in because NO_DWARF=1)

$

[Ingo Molnar]

Very nice!

Thanks,

Ingo

[Ingo Molnar]

So I just noticed this 'perf stat --repeat' oddity:

triton:~/tip> perf stat --repeat 3 -a -e instructions taskset 1 perf bench sched pipe -l 1000000
# Running 'sched/pipe' benchmark:
# Executed 1000000 pipe operations between two processes

Total time: 2.068 [sec]

2.068208 usecs/op
483510 ops/sec
# Running 'sched/pipe' benchmark:
# Executed 1000000 pipe operations between two processes

Total time: 2.097 [sec]

2.097126 usecs/op
476843 ops/sec
# Running 'sched/pipe' benchmark:
# Executed 1000000 pipe operations between two processes

Total time: 2.091 [sec]

2.091716 usecs/op
478076 ops/sec

Performance counter stats for 'system wide' (3 runs):

12,690,156,407 instructions

2.087612423 seconds time elapsed ( +- 0.43% )

the stddev printout of 'instructions' is gone! This defeats the main purpose of
--repeat.

The 'elapsed' time +- stddev/noise display (which is still present) is only part
of the story.

I'm pretty sure we had the printout for all the measured fields a couple of months
ago - does any of you know what happened to it?

Thanks,

Ingo

[Ingo Molnar]

So it appears it broke somewhere between v4.0 and v4.1, as the v4.0 install
displays:

16,244,802,268 instructions ( +- 23.01% )

2.108676769 seconds time elapsed ( +- 0.86% )


[a few minutes later]

Bisected it down to:

106a94a0f8c207ef4113ce7e32f34a00b3b174e7 is the first bad commit
commit 106a94a0f8c207ef4113ce7e32f34a00b3b174e7
Author: Jiri Olsa <jo...@kernel.org>
Date: Fri Jun 26 11:29:19 2015 +0200

perf stat: Introduce read_counters function

So this look like to be a regression.

Thanks,

Ingo

[Arnaldo Carvalho de Melo]

Em Mon, Jan 25, 2016 at 04:43:33PM -0300, Arnaldo Carvalho de Melo escreveu:

> Em Mon, Jan 25, 2016 at 07:35:11PM +0100, Ingo Molnar escreveu:
> >
> > So it appears it broke somewhere between v4.0 and v4.1, as the v4.0 install
> > displays:
> >
> > 16,244,802,268 instructions ( +- 23.01% )
> >
> > 2.108676769 seconds time elapsed ( +- 0.86% )
> >
> >
> > [a few minutes later]
> >
> > Bisected it down to:
>

> Mel Gorman reported this and Jiri provided a patch that Mel tested and
> verified that it fixed, checking where it is sitting now...

I already sent it your way, its:

198 N C 01/21 Arnaldo Carvalh (1.4K) ├─>[PATCH 06/16] perf stat: Do not clean event's private stats

Please pull my perf-core-for-mingo tag and you should get it, its an one
liner.

- Arnaldo

> - Arnaldo

[Arnaldo Carvalho de Melo]

Em Mon, Jan 25, 2016 at 07:35:11PM +0100, Ingo Molnar escreveu:
>

> So it appears it broke somewhere between v4.0 and v4.1, as the v4.0 install
> displays:
>
> 16,244,802,268 instructions ( +- 23.01% )
>
> 2.108676769 seconds time elapsed ( +- 0.86% )
>
>
> [a few minutes later]
>
> Bisected it down to:

Mel Gorman reported this and Jiri provided a patch that Mel tested and
verified that it fixed, checking where it is sitting now...

- Arnaldo

[Ingo Molnar]

* Arnaldo Carvalho de Melo <ac...@kernel.org> wrote:

> Em Mon, Jan 25, 2016 at 04:43:33PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Jan 25, 2016 at 07:35:11PM +0100, Ingo Molnar escreveu:
> > >
> > > So it appears it broke somewhere between v4.0 and v4.1, as the v4.0 install
> > > displays:
> > >
> > > 16,244,802,268 instructions ( +- 23.01% )
> > >
> > > 2.108676769 seconds time elapsed ( +- 0.86% )
> > >
> > >
> > > [a few minutes later]
> > >
> > > Bisected it down to:
> >
> > Mel Gorman reported this and Jiri provided a patch that Mel tested and
> > verified that it fixed, checking where it is sitting now...
>
> I already sent it your way, its:
>
> 198 N C 01/21 Arnaldo Carvalh (1.4K) ├─>[PATCH 06/16] perf stat: Do not clean event's private stats
>
> Please pull my perf-core-for-mingo tag and you should get it, its an one
> liner.

Hm, are all of those changes fixes? If not then mind splitting them into a
perf/urgent portion as well?

Thanks!

Ingo

[Arnaldo Carvalho de Melo]

Ok, doing that...

- Arnaldo