- 14 Sep, 2015 23 commits
-
-
Kan Liang authored
This information will come from perf.data files of from the current system, cached when needed, such as when the 'socket' sort order gets introduced. Signed-off-by:
Kan Liang <kan.liang@intel.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1441377946-44429-1-git-send-email-kan.liang@intel.com [ Don't blindly use env->cpu[al.cpu].socket_id & use machine->env, fixes by Jiri & Arnaldo ] Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Arnaldo Carvalho de Melo authored
The 'struct machine' represents the machine where the samples were/are being collected, and we also have a 'struct perf_env' with extra details about such machine, that we were collecting at 'perf.data' creation time but we also needed when no perf.data file is being used, such as in 'perf top'. So, get those structs closer together, as they provide a bigger picture of the sample's environment. In 'perf session', when the file argument is NULL, we can assume that the tool is sampling the running machine, so point machine->env to the global put in place in previous patches, while set it to the perf_header.env one when reading from a file. This paves the way for machine->env to be used in perf_event__preprocess_sample to populate addr_location.socket. Tested-by:
Wang Nan <wangnan0@huawei.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-2ajotl0khscutm68exictoy9@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Out of the code to write the cpu topology map in the perf.data file header. Now if one needs the CPU topology map for the running machine, one needs to call perf_env__read_cpu_topology_map(perf_env) and the info will be stored in perf_env.cpu. For now we're using a global perf_env variable, that will have its contents freed after we run a builtin. v2: Check perf_env__read_cpu_topology_map() return in write_cpu_topology() (Kan Liang) Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1441828225-667-5-git-send-email-acme@kernel.orgSigned-off-by: -
Arnaldo Carvalho de Melo authored
We have the tools/lib/ sysfs__read_int() for that, avoid code duplication. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-fqg6vt5ku72pbf54ljg6tmoy@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
E.g.: $ ./cpu__get_max_freq 3200000 It does that, as Kan's patch does, by looking at these files: $ cat /sys/devices/system/cpu/online 0-3 $ ./sysfs__read_ull devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq=3200000 $ I.e. find out the first online CPU, then read its cpufreq info. But do it in tools/lib/api/, so that other tools/ living code can use it, not just perf. Based-on-a-patch-by:
-
Arnaldo Carvalho de Melo authored
To read either an int or an unsigned long long value from the given file. E.g.: $ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 3200000 $ ./sysfs__read_ull devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq=3200000 $ Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-4a12m4d5k8m4qgc1vguocvei@git.kernel.orgSigned-off-by:
-
Kan Liang authored
Get msr pmu type when processing pmu_mappings Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Link: http://lkml.kernel.org/n/tip-3ngei63gepydwxhvytl2wx89@git.kernel.org [ Fixed it up wrt moving perf_env from header.h ] Signed-off-by:
-
Jiri Olsa authored
Adding tools/include into tags directories, to have include definitions reachable via tags/cscope. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
We have no use for it in evsel.h. Tested-by:
-
Arnaldo Carvalho de Melo authored
Since we were not setting it to at least 3 chars ('CPU'), it was being reset to zero when recalculating the columns width when refreshing the screen, in 'perf top'. Fix it. Tested-by: -
Arnaldo Carvalho de Melo authored
Move this from two globals to perf_env global, that eventually will be just perf_header->env or something else, to ease the refactoring series, leave it as a global and go on reading more of its fields, not as part of the header writing process but as a perf_env init one that will be used for perf.data-less situations. Tested-by:
-
Arnaldo Carvalho de Melo authored
In ce80d3be ("perf tools: Rename perf_session_env to perf_env") we forgot to rename a few functions to the "perf_env" prefix, do it now. Tested-by:
-
Arnaldo Carvalho de Melo authored
Since it can be used separately from 'perf_session' and 'perf_header', move it to separate include file and object, next csets will try to move a perf_env__init() routine. Tested-by:
-
Matt Fleming authored
In preparation for introducing more arrays of tests, e.g. "arch tests" (architecture-specific tests), abstract the code to iterate over the list of tests into a helper function. This way, code that uses a 'struct test' doesn't need to worry about how the tests are grouped together and changes to the list of tests doesn't require changes to the code using it. Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Acked-by:
-
Kan Liang authored
This patch test cpu core_id and socket_id which are stored in perf_env. Commiter note: # perf test topo 40: Test topology in session: Ok # perf test -v topo 40: Test topology in session: --- start --- test child forked, pid 31767 templ file: /tmp/perf-test-VTZ1PL CPU 0, core 0, socket 0 CPU 1, core 1, socket 0 CPU 2, core 0, socket 0 CPU 3, core 1, socket 0 test child finished with 0 ---- end ---- Test topology in session: Ok # Based-on-a-patch-by:
-
Jiri Olsa authored
Using tracing_path interface on several places, that more or less copy the functionality of tracing_path interface. Signed-off-by:
-
Jiri Olsa authored
We have all the functionality in fs.c, let's remove unneeded objects. Signed-off-by:
-
Jiri Olsa authored
Switching to the fs.c related filesystem framework. Signed-off-by:
-
Jiri Olsa authored
Making tracing_path__strerror_open_tp message generic by mentioning both debugfs/tracefs words in error message plus the tracing_path instead of debugfs_mountpoint. Signed-off-by:
-
Jan Stancek authored
Signed-off-by:
Jan Stancek <jstancek@redhat.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> 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/d0f42f786bc0e965918e0f422df25617a12a4021.1441181335.git.jstancek@redhat.comSigned-off-by:
-
Jan Stancek authored
objdump output can span across multiple sections: Disassembly of section .text: 0000000000000008 <crc32c+0x8>: 8: 48 89 e5 mov %rsp,%rbp b: 53 push %rbx c: 8b 01 mov (%rcx),%eax <snip> 6b: 90 nop Disassembly of section .init.text: 0000000000000008 <init_module+0x8>: 8: 00 00 add %al,(%rax) a: 00 00 add %al,(%rax) c: 48 89 e5 Stop further reading if an address starts going backwards, assuming we crossed sections. Signed-off-by: -
Jan Stancek authored
Add -z parameter to avoid skipping zero blocks: ffffffff816704fe <sysret_check+0x4b>: ffffffff816704fe: 7b 34 jnp ffffffff81670534 <sysret_signal+0x1c> ... ffffffff81670501 <sysret_careful>: ffffffff81670501: 0f ba e2 03 bt $0x3,%edx ffffffff81670505: 73 11 jae ffffffff81670518 <sysret_signal> Signed-off-by: -
Jan Stancek authored
objdump output can contain repeated bytes. At the moment test reads all output sequentially, assuming each address is represented in output only once: ffffffff8164efb3 <retint_swapgs+0x9>: ffffffff8164efb3: c1 5d 00 eb rcrl $0xeb,0x0(%rbp) ffffffff8164efb7: 00 4c 8b 5c add %cl,0x5c(%rbx,%rcx,4) ffffffff8164efb8 <restore_c_regs_and_iret>: ffffffff8164efb8: 4c 8b 5c 24 30 mov 0x30(%rsp),%r11 ffffffff8164efbd: 4c 8b 54 24 38 mov 0x38(%rsp),%r10 Store objdump output to buffer according to offset calculated from address on each line. Signed-off-by:
-
- 13 Sep, 2015 17 commits
-
-
Sukadev Bhattiprolu authored
We currently use PERF_EVENT_TXN flag to determine if we are in the middle of a transaction. If in a transaction, we defer the schedulability checks from pmu->add() operation to the pmu->commit() operation. Now that we have "transaction types" (PERF_PMU_TXN_ADD, PERF_PMU_TXN_READ) we can use the type to determine if we are in a transaction and drop the PERF_EVENT_TXN flag. When PERF_EVENT_TXN is dropped, the cpuhw->group_flag on some architectures becomes unused, so drop that field as well. This is an extension of the Powerpc patch from Peter Zijlstra to s390, Sparc and x86 architectures. Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/1441336073-22750-11-git-send-email-sukadev@linux.vnet.ibm.comSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Sukadev Bhattiprolu authored
The 24x7 counters in Powerpc allow monitoring a large number of counters simultaneously. They also allow reading several counters in a single HCALL so we can get a more consistent snapshot of the system. Use the PMU's transaction interface to monitor and read several event counters at once. The idea is that users can group several 24x7 events into a single group of events. We use the following logic to submit the group of events to the PMU and read the values: pmu->start_txn() // Initialize before first event for each event in group pmu->read(event); // Queue each event to be read pmu->commit_txn() // Read/update all queuedcounters The ->commit_txn() also updates the event counts in the respective perf_event objects. The perf subsystem can then directly get the event counts from the perf_event and can avoid submitting a new ->read() request to the PMU. Thanks to input from Peter Zijlstra. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/1441336073-22750-10-git-send-email-sukadev@linux.vnet.ibm.comSigned-off-by:
-
Sukadev Bhattiprolu authored
Define a new PERF_PMU_TXN_READ interface to read a group of counters at once. pmu->start_txn() // Initialize before first event for each event in group pmu->read(event); // Queue each event to be read rc = pmu->commit_txn() // Read/update all queued counters Note that we use this interface with all PMUs. PMUs that implement this interface use the ->read() operation to _queue_ the counters to be read and use ->commit_txn() to actually read all the queued counters at once. PMUs that don't implement PERF_PMU_TXN_READ ignore ->start_txn() and ->commit_txn() and continue to read counters one at a time. Thanks to input from Peter Zijlstra. Signed-off-by: -
Sukadev Bhattiprolu authored
When we implement the ability to read several counters at once (using the PERF_PMU_TXN_READ transaction interface), perf_event_read() can fail when the 'group' parameter is true (eg: trying to read too many events at once). For now, have perf_event_read() return an integer. Ignore the return value when the 'group' parameter is false. Signed-off-by:
-
Peter Zijlstra authored
In order to enable the use of perf_event_read(.group = true), we need to invert the sibling-child loop nesting of perf_read_group(). Currently we iterate the child list for each sibling, this precludes using group reads. Flip things around so we iterate each group for each child. Signed-off-by:
-
Peter Zijlstra authored
Enable perf_event_read() to update entire groups at once, this will be useful for read transactions. Signed-off-by:
-
Peter Zijlstra (Intel) authored
In order to free up the perf_event_read_group() name: s/perf_event_read_\(one\|group\)/perf_read_\1/g s/perf_read_hw/__perf_read/g Signed-off-by:
-
Sukadev Bhattiprolu authored
perf_event_read() does two things: - call the PMU to read/update the counter value, and - compute the total count of the event and its children Not all callers need both. perf_event_reset() for instance needs the first piece but doesn't need the second. Similarly, when we implement the ability to read a group of events using the transaction interface, we would need the two pieces done independently. Break up perf_event_read() and have it just read/update the counter and have the callers compute the total count if necessary. Signed-off-by:
-
Sukadev Bhattiprolu authored
Currently, the PMU interface allows reading only one counter at a time. But some PMUs like the 24x7 counters in Power, support reading several counters at once. To leveage this functionality, extend the transaction interface to support a "transaction type". The first type, PERF_PMU_TXN_ADD, refers to the existing transactions, i.e. used to _schedule_ all the events on the PMU as a group. A second transaction type, PERF_PMU_TXN_READ, will be used in a follow-on patch, by the 24x7 counters to read several counters at once. Extend the transaction interfaces to the PMU to accept a 'txn_flags' parameter and use this parameter to ignore any transactions that are not of type PERF_PMU_TXN_ADD. Thanks to Peter Zijlstra for his input. Signed-off-by:
-
Sukadev Bhattiprolu authored
In ->commit_txn() 'cpuc' is already initialized when it is declared, so we can remove the duplicate assignment. Signed-off-by:
-
Peter Zijlstra authored
Signed-off-by:
-
Huaitong Han authored
If KVM does not support INTEL_PT, guest MSR_IA32_RTIT_CTL reading will produce host warning like "kvm [2469]: vcpu0 unhandled rdmsr: 0x570". Guest can determine whether the CPU supports Intel_PT according to CPUID, so test_cpu_cap function is added before rdmsr,and it is more in line with the code style. Signed-off-by:
Huaitong Han <huaitong.han@intel.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: acme@kernel.org Link: http://lkml.kernel.org/r/1441009262-9792-1-git-send-email-huaitong.han@intel.comSigned-off-by:
-
Kirill Tkhai authored
cgroup_exit() is not called from copy_process() after commit: e8604cb4 ("cgroup: fix spurious lockdep warning in cgroup_exit()") from do_exit(). So this check is useless and the comment is obsolete. Signed-off-by:
Kirill Tkhai <ktkhai@odin.com> Signed-off-by:
-
Kan Liang authored
This patch fixes an issue which introduced by commit 1a78d937 ("perf/x86/intel: Streamline LBR MSR handling in PMI"). The old patch not only avoids writing LBR_SELECT MSR in PMI, but also avoids updating lbr_select variable. So in PMI, FREEZE_LBRS_ON_PMI bit is always mistakenly set for IA32_DEBUGCTLMSR MSR, which causes superfluous increase/decrease of LBR_TOS when collecting LBR callstack. Reported-by:
Milian Wolff <mail@milianw.de> Signed-off-by:
-
Alexander Shishkin authored
BTS leaks kernel addresses even in userspace-only mode due to imprecise IP sampling, so sometimes syscall entry points or page fault handler addresses end up in a userspace trace. Now, intel_bts driver exports trace data zero-copy, it does not scan through it to filter out the kernel addresses and it's would be a O(n) job. To work around this situation, this patch forbids the use of intel_bts driver by unprivileged users on systems with the paranoid setting above the (kernel's) default "1", which still allows kernel profiling. In other words, using intel_bts driver implies kernel tracing, regardless of the "exclude_kernel" attribute setting. Signed-off-by:
-
Alexander Shishkin authored
BTS leaks kernel addresses even in userspace-only mode due to imprecise IP sampling, so sometimes syscall entry points or page fault handler addresses end up in a userspace trace. Since this driver uses a relatively small buffer for BTS records and it has to iterate through them anyway, it can also take on the additional job of filtering out the records that contain kernel addresses when kernel space tracing is not enabled. This patch changes the bts code to skip the offending records from perf output. In order to request the exact amount of space on the ring buffer, we need to do an extra pass through the records to know how many there are of the valid ones, but considering the small size of the buffer, this extra pass adds very little overhead to the nmi handler. This way we won't end up with awkward IP samples with zero IPs in the perf stream. Signed-off-by:
-
Adrian Hunter authored
When TSC is stable perf/sched clock is based on it. However the conversion from cycles to nanoseconds is not as accurate as it could be. Because CYC2NS_SCALE_FACTOR is 10, the accuracy is +/- 1/2048 The change is to calculate the maximum shift that results in a multiplier that is still a 32-bit number. For example all frequencies over 1 GHz will have a shift of 32, making the accuracy of the conversion +/- 1/(2^33). That is achieved by using the 'clocks_calc_mult_shift()' function. Signed-off-by:
-
