Namhyung Kim noticed that the autodep .d file inclusion rule was
unnecessarily complicated:
> > +-include *.d */*.d
>
> Hmm.. this */*.d part is really needed?
Only include *.d files.
Reported-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Namhyung Kim noticed that the stackprotector testcase was incomplete:
> The flag being checked should be -"W"stack-protector instead of
> -"f"stack-protector. And the gcc manpage says that -Wstack-protector is
> only active when -fstack-protector is active. So the end result should
> look like
>
> $(BUILD) -Werror -fstack-protector -Wstack-protector
Add -Wstack-protector.
Reported-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Namhyung Kim noticed that the volatile-register-var feature check
is superfluous:
> The gcc manpage says this warning is enabled by -Wall, and we add -Wall
> to CFLAGS before doing feature checks. So all gcc versions that support
> -Wvolatile-register-var enables it by default without this check and
> older gcc versions will always fail the feature check.
Remove it - this will further speed up feature checks.
Reported-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Namhyung Kim reported these duplicate DPACKAGE definitions:
test-libbfd:
$(BUILD) -DPACKAGE='perf' -DPACKAGE=perf -lbfd -ldl
Fix all affected places and use Namhyung's suggestion that the
definition should look like a normal C string: -DPACKAGE='"perf"'.
Reported-by: Namhyung Kim <namhyung@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Arnaldo reported that 'make DEBUG=1' does not work anymore.
The reason is that 'Makefile' only passes it through to
'Makefile.perf' via the environment, but 'Makefile.perf'
checks that it's a command line option:
ifeq ("$(origin DEBUG)", "command line")
PERF_DEBUG = $(DEBUG)
endif
So pass it through properly, and also clean up DEBUG parameter
handling while at it and fix a couple of annoyances:
- DEBUG=0 used to be interpreted as 'debugging on'. Turn it
into 'debugging off' instead.
- Same was the case for 'DEBUG=' - turn that into debug-off
as well.
- Pass in just a clean, sanitized 'DEBUG' value and get rid of
the intermediate, unnecessary PERF_DEBUG variable.
Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
trace-event-parse.c:parse_proc_kallsyms()
Old GCC (4.4.2) does not see through the code flow of get_srcline() and
gets confused about the status of 'file' and 'line':
CC /tmp/build/perf/util/srcline.o
cc1: warnings being treated as errors
util/srcline.c: In function ¿get_srcline¿:
util/srcline.c:226: error: ¿file¿ may be used uninitialized in this function
util/srcline.c:227: error: ¿line¿ may be used uninitialized in this function
make[1]: *** [/tmp/build/perf/util/srcline.o] Error 1
make: *** [install] Error 2
make: Leaving directory `/home/acme/git/linux/tools/perf'
[acme@fedora12 linux]$
Help out GCC by initializing 'file' and 'line'.
Signed-off-by: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@gmail.com>
Link: http://lkml.kernel.org/n/tip-h8k7h49z3cndqgjdftkmm9f8@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Currently, execution of 'perf trace' reports the following cryptic
message to the user:
$ perf trace
Couldn't read the raw_syscalls tracepoints information!
Typically this happens because the user does not have permissions to
read the debugfs filesystem. Also handle the case when the kernel was
not compiled with debugfs support or when it isn't mounted.
Now, the tool prints detailed error messages:
$ perf trace
Error: Unable to find debugfs
Hint: Was your kernel was compiled with debugfs support?
Hint: Is the debugfs filesystem mounted?
Hint: Try 'sudo mount -t debugfs nodev /sys/kernel/debug'
$ perf trace
Error: No permissions to read /sys/kernel/debug//tracing/events/raw_syscalls
Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/'
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1380863851-14460-1-git-send-email-artagnon@gmail.com
[ Added ready to use commands to fix the issues as extra hints, use the
current debugfs mount point when reporting permission error, use
strerror_r instead of the deprecated sys_errlist, as reported by David Ahern ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
'make install' used to show all the install lines, which is way too
verbose to be really informative to the user.
Implement summary output instead:
comet:~/tip/tools/perf> make install
BUILD: Doing 'make -j12' parallel build
SUBDIR Documentation
INSTALL Documentation-man
INSTALL binaries
INSTALL libexec
INSTALL perf-archive
INSTALL perl-scripts
INSTALL python-scripts
INSTALL bash_completion-script
INSTALL tests
'make install V=1' will still show the old, detailed output.
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1381312169-17354-5-git-send-email-mingo@kernel.org
[ Fixed conflict with libperf-gtk patches in acme/perf/core, cope with 'trace' alias ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The various build lines from libtraceevent and perf mix up during a
parallel build and produce unaligned output like:
CC builtin-buildid-list.o
CC builtin-buildid-cache.o
CC builtin-list.o
CC FPIC trace-seq.o
CC builtin-record.o
CC FPIC parse-filter.o
CC builtin-report.o
CC builtin-stat.o
CC FPIC parse-utils.o
CC FPIC kbuffer-parse.o
CC builtin-timechart.o
CC builtin-top.o
CC builtin-script.o
BUILD STATIC LIB libtraceevent.a
CC builtin-probe.o
CC builtin-kmem.o
CC builtin-lock.o
To solve this, harmonize all the build message alignments to be similar
to the kernel's kbuild output: prefixed by two spaces and 11-char wide.
After the patch the output looks pretty tidy, even if output lines get
mixed up:
CC builtin-annotate.o
FLAGS: * new build flags or cross compiler
CC builtin-bench.o
AR liblk.a
CC bench/sched-messaging.o
CC FPIC event-parse.o
CC bench/sched-pipe.o
CC FPIC trace-seq.o
CC bench/mem-memcpy.o
CC bench/mem-memset.o
CC FPIC parse-filter.o
CC builtin-diff.o
CC builtin-evlist.o
CC builtin-help.o
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1381312169-17354-3-git-send-email-mingo@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Task comm's are getting lost when processing events from a file. The
problem is that the trace struct used by the live processing has its
host machine and the perf-session used for file based processing has its
host machine. Fix by having both references point to the same machine.
Before:
0.030 ( 0.001 ms): :27743/27743 brk( ...
0.057 ( 0.004 ms): :27743/27743 mmap(len: 4096, prot: READ|WRITE, flags: ...
0.075 ( 0.006 ms): :27743/27743 access(filename: 0x7f3809fbce00, mode: R ...
0.091 ( 0.005 ms): :27743/27743 open(filename: 0x7f3809fba14c, flags: CLOEXEC ...
...
After:
0.030 ( 0.001 ms): make/27743 brk( ...
0.057 ( 0.004 ms): make/27743 mmap(len: 4096, prot: READ|WRITE, flags: ...
0.075 ( 0.006 ms): make/27743 access(filename: 0x7f3809fbce00, mode: R ...
0.091 ( 0.005 ms): make/27743 open(filename: 0x7f3809fba14c, flags: CLOEXEC ...
...
Signed-off-by: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1380395584-9025-4-git-send-email-dsahern@gmail.com
[ Moved creation of new host machine to a separate constructor: machine__new_host() ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The perf_evlist__mmap_read used 'union perf_event' as a placeholder for
event crossing the mmap boundary.
This is ok for sample shorter than ~PATH_MAX. However we could grow up
to the maximum sample size which is 16 bits max.
I hit this overflow issue when using 'perf top -G dwarf' which produces
sample with the size around 8192 bytes. We could configure any valid
sample size here using: '-G dwarf,size'.
Using array with sample max size instead for the event placeholder. Also
adding another safe check for the dynamic size of the user stack.
TODO: The 'struct perf_mmap' is quite big now, maybe we could use some
lazy allocation for event_copy size.
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: David Ahern <dsahern@gmail.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1380721599-24285-1-git-send-email-jolsa@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Patch adds more subtle handling of -C and -N parameters in
parse_{cpu,node}_setup_list() functions when there isn't enough NUMA
nodes or CPUs present. Instead of assertion and terminating benchmark,
partial test is skipped with error message and perf will continue to the
next one.
Fixed problem can be easily reproduced on machine with only one NUMA
node:
# Running numa/mem benchmark...
# Running main, "perf bench numa mem -a"
...
# Running RAM-bw-remote, "perf bench numa mem -p 1 -t 1 -P 1024 -C 0 -M 1 -s
perf: bench/numa.c:622: parse_setup_node_list: Assertion `!(bind_node_0 < 0 ||
bind_node_0 >= g->p.nr_nodes)' failed.
Aborted
Signed-off-by: Petr Holasek <pholasek@redhat.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Petr Benas <pbenas@redhat.com>
Link: http://lkml.kernel.org/r/1380821325-4017-1-git-send-email-pholasek@redhat.com
Signed-off-by: Petr Benas <pbenas@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When only the instructions event is requested:
$ perf stat -e instructions git s
M builtin-stat.c
Performance counter stats for 'git s':
917,453,420 instructions # 0.00 insns per cycle
0.213002926 seconds time elapsed
The 0.00 insns per cycle comment in the output is totally bogus and
misleading. It happens because update_shadow_stats() doesn't touch
runtime_cycles_stats when only the instructions event is requested. So,
omit printing the bogus data altogether.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1380616604-4077-1-git-send-email-artagnon@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When only the cycles event is requested:
$ perf stat -e cycles dd if=/dev/zero of=/dev/null count=1000000
1000000+0 records in
1000000+0 records out
512000000 bytes (512 MB) copied, 0.26123 s, 2.0 GB/s
Performance counter stats for 'dd if=/dev/zero of=/dev/null count=1000000':
911,626,453 cycles # 0.000 GHz
0.262113350 seconds time elapsed
The 0.000 GHz comment in the output is totally bogus and misleading. It
happens because update_shadow_stats() doesn't touch runtime_nsecs_stats;
it is only written when a requested counter matches a SW_TASK_CLOCK. In
our case, since we have only requested HW_CPU_CYCLES,
runtime_nsecs_stats is unavailable. So, omit printing the comment
altogether.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1380539585-23859-3-git-send-email-artagnon@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For live sessions we can just access /proc to map an fd to its path, on
a best effort way, i.e. sometimes the fd will have gone away when we try
to do the mapping, as it is done in a lazy way, only when a reference to
such fd is made then the path will be looked up in /proc.
This is disabled when processing perf.data files, where we will have to
have a way to get getname events, be it via an on-the-fly 'perf probe'
event or after a vfs_getname tracepoint is added to the kernel.
A first step will be to synthesize such event for the use cases where
the threads in the monitored workload exist already.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-1r1ti33ye1666jezu2d8q1c3@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
