We were using it at 10 kHz, which doesn't work in machines where somehow
the max freq was auto reduced by the kernel:
[root@ssdandy ~]# perf test 19
19: Test software clock events have valid period values : FAILED!
[root@ssdandy ~]# perf test -v 19
19: Test software clock events have valid period values :
--- start ---
Couldn't open evlist: Invalid argument
---- end ----
Test software clock events have valid period values: FAILED!
[root@ssdandy ~]#
[root@ssdandy ~]# cat /proc/sys/kernel/perf_event_max_sample_rate
7000
Reducing it to 500 Hz should be good enough for this test and also
shouldn't affect what it is testing.
But warn the user if it fails, informing the knob and the freq tried.
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: Namhyung Kim <namhyung@kernel.org>
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-548rhj1uo6xbwnxa95kw3hqe@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We were not checking if we successfully opened the counters, i.e. if
sys_perf_event_open worked, when it doesn't in this test, we were
continuing anyway and then segfaulting when trying to access the file
descriptor array, that at that point had been freed in perf_evlist__open
error path:
[root@ssdandy ~]# perf test -v 19
19: Test software clock events have valid period values :
--- start ---
Segmentation fault (core dumped)
[root@ssdandy ~]#
Do the check and bail out instead.
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-6qy8ljkn0e9hm7bh7keo5z68@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Most uses of the evsel constructor are followed by a call to
perf_evlist__add with an idex of evlist->nr_entries, so make rename
the current constructor to perf_evsel__new_idx and remove the need
for passing the constructor for the common case.
We still need the new_idx variant because the way groups are handled,
with evsel->nr_members holding the number of entries in an evlist,
partitioning the evlist into sublists inside a single linked list.
This asks for a clarifying refactoring, but for now simplify the non
parser cases, so that tool writers don't have to bother with evsel idx
setting.
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-zy9tskx6jqm2rmw7468zze2a@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This way we can later delimit a lifecycle for the COMM and map a hist to
a precise COMM:timeslice couple.
PERF_RECORD_COMM and PERF_RECORD_FORK events that don't have
PERF_SAMPLE_TIME samples can only send 0 value as a timestamp and thus
should overwrite any previous COMM on a given thread because there is no
sensible way to keep track of all the comms lifecycles in a thread
without time informations.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Jiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-6tyow99vgmmtt9qwr2u2lqd7@git.kernel.org
[ Made it cope with PERF_RECORD_MMAP2 ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The "struct perf_event_attr setup" entry in 'perf test' is in fact a
series of tests that will exec the tools, passing different sets of
command line arguments to then intercept the sys_perf_event_open
syscall, in user space, to check that the perf_event_attr->sample_type
and other feature request bits are setup as expected.
We recently restored the callchain requesting command line argument, -g,
to not require a parameter ("dwarf" or "fp"), instead using a default
("fp" for now) and making the long option variant, --call-chain, be the
one to be used when a different callchain collection method is
preferred.
The "struct perf_event_attr setup" test failed because we forgot to
update the tests involving callchains, not switching from, '-g dwarf' to
'--call-chain dwarf', making 'perf test' detect it:
[root@sandy ~]# perf test -v 13
13: struct perf_event_attr setup :
--- start ---
running '/home/acme/libexec/perf-core/tests/attr/test-record-basic'
running '/home/acme/libexec/perf-core/tests/attr/test-record-branch-any'
<SNIP>
running '/home/acme/libexec/perf-core/tests/attr/test-record-graph-default'
running '/home/acme/libexec/perf-core/tests/attr/test-record-graph-dwarf'
expected sample_type=12583, got 295
expected exclude_callchain_user=1, got 0
expected sample_stack_user=8192, got 0
FAILED '/home/acme/libexec/perf-core/tests/attr/test-record-graph-dwarf' - match failure
---- end ----
struct perf_event_attr setup: FAILED!
[root@sandy ~]#
Fix all of them now to use --call-chain when explicitely specifying a
method.
There is still work to do, as '-g fp', for instance, passed without
problems.
In that case 'perf test' saw no problems as the intercepted syscall got
the bits as expected, i.e. the default is 'fp', but the fact that 'fp'
may be an existing program and the specified workload would then be
passed as a parameter to it is an usability problem that needs fixing.
Next merge window tho.
Acked-by: Jiri Olsa <jolsa@redhat.com>
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-jr3oq1k5iywnp7vvqlslzydm@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This patch adds support for the new PERF_RECORD_MMAP2 record type
exposed by the kernel. This is an extended PERF_RECORD_MMAP record.
It adds for each file-backed mapping the device major, minor number and
the inode number and generation.
This triplet uniquely identifies the source of a file-backed mapping. It
can be used to detect identical virtual mappings between processes, for
instance.
The patch will prefer MMAP2 over MMAP.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1377079825-19057-3-git-send-email-eranian@google.com
[ Cope with 314add6 "Change machine__findnew_thread() to set thread pid",
fix 'perf test' regression test entry affected,
use perf_missing_features.mmap2 to fallback to not using .mmap2 in older kernels,
so that new tools can work with kernels where this feature is not present ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Arnaldo Carvalho de Melo
Peter Zijlstra
Jiri Olsa
Namhyung Kim
Adrian Hunter
Frederic Weisbecker
Ingo Molnar
Zhouyi Zhou
Felipe Pena
Andi Kleen
Stephane Eranian