* [PATCH] perf tools: Do not show trace command if it's not compiled in
@ 2015-12-20 16:31 Jiri Olsa
2016-01-12 11:23 ` Ingo Molnar
0 siblings, 1 reply; 10+ messages in thread
From: Jiri Olsa @ 2015-12-20 16:31 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: lkml, David Ahern, Ingo Molnar, Namhyung Kim, Peter Zijlstra
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
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] perf tools: Do not show trace command if it's not compiled in
2015-12-20 16:31 [PATCH] perf tools: Do not show trace command if it's not compiled in Jiri Olsa
@ 2016-01-12 11:23 ` Ingo Molnar
2016-01-12 14:29 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2016-01-12 11:23 UTC (permalink / raw)
To: Jiri Olsa
Cc: Arnaldo Carvalho de Melo, lkml, David Ahern, Namhyung Kim,
Peter Zijlstra
* 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] perf tools: Do not show trace command if it's not compiled in
2016-01-12 11:23 ` Ingo Molnar
@ 2016-01-12 14:29 ` Arnaldo Carvalho de Melo
2016-01-13 10:42 ` Ingo Molnar
0 siblings, 1 reply; 10+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-01-12 14:29 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Jiri Olsa, lkml, David Ahern, Namhyung Kim, Peter Zijlstra
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] perf tools: Do not show trace command if it's not compiled in
2016-01-12 14:29 ` Arnaldo Carvalho de Melo
@ 2016-01-13 10:42 ` Ingo Molnar
2016-01-25 18:22 ` 'perf stat --repeat N' oddity/regression Ingo Molnar
0 siblings, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2016-01-13 10:42 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Jiri Olsa, lkml, David Ahern, Namhyung Kim, Peter Zijlstra
* 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* 'perf stat --repeat N' oddity/regression
2016-01-13 10:42 ` Ingo Molnar
@ 2016-01-25 18:22 ` Ingo Molnar
2016-01-25 18:35 ` Ingo Molnar
0 siblings, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2016-01-25 18:22 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Jiri Olsa, lkml, David Ahern, Namhyung Kim, Peter Zijlstra
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 'perf stat --repeat N' oddity/regression
2016-01-25 18:22 ` 'perf stat --repeat N' oddity/regression Ingo Molnar
@ 2016-01-25 18:35 ` Ingo Molnar
2016-01-25 19:43 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2016-01-25 18:35 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Jiri Olsa, lkml, David Ahern, Namhyung Kim, Peter Zijlstra
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 'perf stat --repeat N' oddity/regression
2016-01-25 18:35 ` Ingo Molnar
@ 2016-01-25 19:43 ` Arnaldo Carvalho de Melo
2016-01-25 19:48 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 10+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-01-25 19:43 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Jiri Olsa, lkml, David Ahern, Namhyung Kim, Peter Zijlstra
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 'perf stat --repeat N' oddity/regression
2016-01-25 19:43 ` Arnaldo Carvalho de Melo
@ 2016-01-25 19:48 ` Arnaldo Carvalho de Melo
2016-01-26 8:08 ` Ingo Molnar
0 siblings, 1 reply; 10+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-01-25 19:48 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Jiri Olsa, lkml, David Ahern, Namhyung Kim, Peter Zijlstra
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 'perf stat --repeat N' oddity/regression
2016-01-25 19:48 ` Arnaldo Carvalho de Melo
@ 2016-01-26 8:08 ` Ingo Molnar
2016-01-26 14:18 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2016-01-26 8:08 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Jiri Olsa, lkml, David Ahern, Namhyung Kim, Peter Zijlstra
* 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: 'perf stat --repeat N' oddity/regression
2016-01-26 8:08 ` Ingo Molnar
@ 2016-01-26 14:18 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 10+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-01-26 14:18 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Jiri Olsa, lkml, David Ahern, Namhyung Kim, Peter Zijlstra
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-01-26 14:18 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-20 16:31 [PATCH] perf tools: Do not show trace command if it's not compiled in Jiri Olsa
2016-01-12 11:23 ` Ingo Molnar
2016-01-12 14:29 ` Arnaldo Carvalho de Melo
2016-01-13 10:42 ` Ingo Molnar
2016-01-25 18:22 ` 'perf stat --repeat N' oddity/regression Ingo Molnar
2016-01-25 18:35 ` Ingo Molnar
2016-01-25 19:43 ` Arnaldo Carvalho de Melo
2016-01-25 19:48 ` Arnaldo Carvalho de Melo
2016-01-26 8:08 ` Ingo Molnar
2016-01-26 14:18 ` Arnaldo Carvalho de Melo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.