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

[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-eys6x7vq4y9363s2wkjwan3k@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@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

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

[Ingo Molnar]

* Jiri Olsa <jolsa@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

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

[Arnaldo Carvalho de Melo]

Em Tue, Jan 12, 2016 at 12:23:41PM +0100, Ingo Molnar escreveu:
> 
> * Jiri Olsa <jolsa@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)

  $
 
>  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

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

[Ingo Molnar]

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

> Em Tue, Jan 12, 2016 at 12:23:41PM +0100, Ingo Molnar escreveu:
> > 
> > * Jiri Olsa <jolsa@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)

Very nice!

Thanks,

	Ingo

'perf stat --repeat N' oddity/regression

[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

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

[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 <jolsa@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

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

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

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

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

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

[Ingo Molnar]

* Arnaldo Carvalho de Melo <acme@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

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

[Arnaldo Carvalho de Melo]

Em Tue, Jan 26, 2016 at 09:08:22AM +0100, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo <acme@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?

Ok, doing that...

- Arnaldo