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

PATCH In review Jiri Olsa 3 participants 10 messages Dec 20, 2015 – Jan 26, 2016 perf events

lore

Share & tools

lore

Jiri Olsa

author reviewer

2015-12-20 16:32 UTC #0 lore raw

PATCH 1/1 perf tools: Do not show trace command if it's not compiled in

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/[email protected] open here

Signed-off-by Jiri Olsa <[email protected]>

---
 tools/perf/command-list.txt         |  2 +-
 tools/perf/util/generate-cmdlist.sh | 15 +++++++++++++++
 2 files changed, 16 insertions(+), 1 deletion(-)

tools/perf/command-list.txt +1 -1

index acc3ea7d90b7..ab5cbaa170d0 100644
@@ -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

tools/perf/util/generate-cmdlist.sh +15 -0

index 36a885d2cd22..0ac2037c970c 100755
@@ -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 "};"

Signature · 1 line

2.4.3

Ingo Molnar

2016-01-12 11:23 UTC #1 lore raw

Quoted 10 lines · 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.

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

maintainer

2016-01-12 14:30 UTC #2 lore raw

Em Tue, Jan 12, 2016 at 12:23:41PM +0100, Ingo Molnar escreveu:

Quoted 10 lines · Jiri Olsa

Quoted 8 lines
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.

Quoted 5 lines

Quoted 3 lines
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)

Quoted 46 lines

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

Ingo Molnar

2016-01-13 10:43 UTC #3 lore raw

Quoted 30 lines · Arnaldo Carvalho de Melo

Em Tue, Jan 12, 2016 at 12:23:41PM +0100, Ingo Molnar escreveu:
Quoted 10 lines · Jiri Olsa
Quoted 8 lines
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.
Quoted 5 lines
Quoted 3 lines
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

Quoted 7 lines

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)

Very nice!

Thanks,

Ingo

Ingo Molnar

2016-01-25 18:22 UTC #4 lore raw

'perf stat --repeat N' oddity/regression

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

2016-01-25 18:35 UTC #5 lore raw

Re: 'perf stat --repeat N' oddity/regression

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 <[email protected]>
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

maintainer

2016-01-25 19:43 UTC #6 lore raw

Re: 'perf stat --repeat N' oddity/regression

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

Quoted 4 lines

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

Quoted 8 lines

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

Quoted 12 lines

106a94a0f8c207ef4113ce7e32f34a00b3b174e7 is the first bad commit commit 106a94a0f8c207ef4113ce7e32f34a00b3b174e7
Author: Jiri Olsa <[email protected]>
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

maintainer

2016-01-25 19:48 UTC #7 lore raw

Re: 'perf stat --repeat N' oddity/regression

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

Quoted 10 lines

Em Mon, Jan 25, 2016 at 07:35:11PM +0100, Ingo Molnar escreveu:
Quoted 9 lines
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% )

Quoted 6 lines

Quoted 3 lines
[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

Quoted 14 lines

- Arnaldo
Quoted 12 lines
106a94a0f8c207ef4113ce7e32f34a00b3b174e7 is the first bad commit commit 106a94a0f8c207ef4113ce7e32f34a00b3b174e7
Author: Jiri Olsa <[email protected]>
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

Ingo Molnar

2016-01-26 08:08 UTC #8 lore raw

Re: 'perf stat --repeat N' oddity/regression

Quoted 18 lines · Arnaldo Carvalho de Melo

Em Mon, Jan 25, 2016 at 04:43:33PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 10 lines
Em Mon, Jan 25, 2016 at 07:35:11PM +0100, Ingo Molnar escreveu:
Quoted 9 lines
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% )
Quoted 6 lines
Quoted 3 lines
[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...

Quoted 6 lines

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

maintainer

2016-01-26 14:18 UTC #9 lore raw

Re: 'perf stat --repeat N' oddity/regression

Em Tue, Jan 26, 2016 at 09:08:22AM +0100, Ingo Molnar escreveu:

Quoted 23 lines · Arnaldo Carvalho de Melo

Quoted 21 lines
Em Mon, Jan 25, 2016 at 04:43:33PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 10 lines
Em Mon, Jan 25, 2016 at 07:35:11PM +0100, Ingo Molnar escreveu:
Quoted 9 lines
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% )
Quoted 6 lines
Quoted 3 lines
[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:

Quoted 7 lines

Quoted 4 lines
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?

Ok, doing that...

- Arnaldo