- 18 Feb, 2014 22 commits
-
-
Arnaldo Carvalho de Melo authored
There are no users outside the file that defines it. 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-sybihqycxrmssa4df9516jib@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Borislav Petkov authored
This was needed at the time before e66eed65 ("list: remove prefetching from regular list iterators") where the list iterators did prefetch elements. This turned out to be counter-productive and hurt performance and they were removed. Which makes the prefetch.h header unused so drop it. Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Robert Richter <rric@kernel.org> Link: http://lkml.kernel.org/r/1391611914-26054-4-git-send-email-bp@alien8.deSigned-off-by:
-
Borislav Petkov authored
Put it into tools/include/ for general usage. Signed-off-by:
-
Borislav Petkov authored
Move to generic library and kill magic.h as it is needed only in fs.h. Signed-off-by:
-
Jiri Olsa authored
Making perf_reg_value function global (formely reg_value), because it's going to be used globaly across all code providing the dwarf post unwind feature. Changing its prototype to be generic: -int reg_value(unw_word_t *valp, struct regs_dump *regs, int id) +int perf_reg_value(u64 *valp, struct regs_dump *regs, int id); Changing the valp type from libunwind specific 'unw_word_t' to u64. Signed-off-by:
Jiri Olsa <jolsa@redhat.com> Acked-by:
Jean Pihet <jean.pihet@linaro.org> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jean Pihet <jean.pihet@linaro.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/1389098853-14466-13-git-send-email-jolsa@redhat.comSigned-off-by:
-
Jiri Olsa authored
Introducing global macro HAVE_DWARF_UNWIND_SUPPORT to indicate we have dwarf unwind support. Any library providing the dwarf post unwind support will enable this macro. Signed-off-by:
-
Jiri Olsa authored
Renaming unwind__arch_reg_id into libunwind__arch_reg_id, so it's clear it's specific to libunwind. Signed-off-by:
-
Jiri Olsa authored
We are going to add libdw library support to do dwarf post unwind. Making the code ready by moving libunwind dwarf post unwind stuff into separate object. Signed-off-by:
-
Jiri Olsa authored
Adding mask info into struct regs_dump to make the registers information compact. The mask was always passed along, so logically the mask info fits more into the struct regs_dump. Signed-off-by:
-
Jiri Olsa authored
We are not interested in zero addresses in callchain, do not report them. Signed-off-by:
-
Jiri Olsa authored
The 'unwind__get_entries' function currently returns 'max_stack + 1' entries (instead of exact max_stack entries), because max_stack value does not get decremented for the first entry. This fix makes dwarf-unwind test pass. Signed-off-by:
-
Jiri Olsa authored
Adding dwarf unwind test, that setups live machine data over the perf test thread and does the remote unwind. At this moment this test fails due to bug in the max_stack processing in unwind__get_entries function. This is fixed in following patch. Need to use -fno-optimize-sibling-calls for test compilation, otherwise 'krava_*' function calls are optimized into jumps and ommited from the stack unwind. So far it's enabled only for x86. Signed-off-by:
-
Jiri Olsa authored
Introducing perf_regs_load function, which is going to be used for dwarf unwind test in following patches. It takes single argument as a pointer to the regs dump buffer and populates it with current registers values. Signed-off-by:
-
Jiri Olsa authored
Properly destroying trace_seq object. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> 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> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/1391377150-23920-2-git-send-email-jolsa@redhat.comSigned-off-by:
-
Jiri Olsa authored
Adding people readable output for callchain debug, to get following '-v' output: $ perf record -v -g ls callchain: type DWARF callchain: stack dump size 4096 ... Signed-off-by:
-
Jiri Olsa authored
Adding call-graph option support into .perfconfig file, so it's now possible use call-graph option like: [top] call-graph = fp [record] call-graph = dwarf,8192 Above options ONLY setup the unwind method. To enable perf record/top to actually use it the command line option -g/-G must be specified. The --call-graph option overloads .perfconfig setup. Assuming above configuration: $ perf record -g ls - enables dwarf unwind with user stack size dump 8192 bytes $ perf top -G - enables frame pointer unwind $ perf record --call-graph=fp ls - enables frame pointer unwind $ perf top --call-graph=dwarf,4096 ls - enables dwarf unwind with user stack size dump 4096 bytes Signed-off-by: -
Jiri Olsa authored
We use PERF_SAMPLE_PERIOD sample type only for frequency setup -F (default) option. The -c does not need store period, because it's always the same. In -c case the report code uses '1' as period. Fixing it to perf_event_attr::sample_period. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
Since all it wants is to get the 'struct record' from the received 'struct perf_tool', and this is already done at the callers of these functions, short circuit it. 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-xz8p659sjpad396vye5t24gx@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Since two of the parameters come from the same 'struct addr_location', rename machine__resolve_bstack() to sample__resolve_bstack() and pass the that addr_location instead. This is also for consistency with the same change that resulted in the sample__resolve_mem() function. 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-99ecqt8jiyyksiyx3se7l5ia@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
Since three of the parameters come from the same 'struct addr_location', rename machine__resolve_mem() to sample__resolve_mem() and pass the that addr_location 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: 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-3f5otpssefh9l5hi1t259h8n@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
We don't need to recalculate cpumode from the perf_event->header field, as this is already available in the struct addr_location->cpumode field. Remove the function signature of functions that receive both perf_event and addr_location parameters but use perf_event just to extract the cpumode. 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-tmct07y7mka54allj82trlnx@git.kernel.orgSigned-off-by:
-
Arnaldo Carvalho de Melo authored
To have some 'perf probe' related fixes needed for further devel work in this tool. Signed-off-by:
-
- 13 Feb, 2014 1 commit
-
-
Arnaldo Carvalho de Melo authored
Supporting decoding the ioctl 'request' parameter needs more work to properly support more architectures, the current approach doesn't work on at least powerpc and sparc, as reported by Ben Hutchings in http://lkml.kernel.org/r/1391593985.3003.48.camel@deadeye.wl.decadent.org.uk . Work around that by making it to be ifdefed for the architectures known to work with the current, limited approach, i386 and x86_64 till better code is written. Reported-by:
Ben Hutchings <ben@decadent.org.uk> Acked-by:
-
- 10 Feb, 2014 4 commits
-
-
Ben Hutchings authored
glibc 2.17 is missing this on sparc, despite the fact that it's not architecture-specific. Signed-off-by:
-
Vince Weaver authored
"perf list" listing of hardware events doesn't work on older ARM devices. The change enabling event detection: commit b41f1cec Author: Namhyung Kim <namhyung.kim@lge.com> Date: Tue Aug 27 11:41:53 2013 +0900 perf list: Skip unsupported events uses the following code in tools/perf/util/parse-events.c: struct perf_event_attr attr = { .type = type, .config = config, .disabled = 1, .exclude_kernel = 1, }; On ARM machines pre-dating the Cortex-A15 this doesn't work, as these machines don't support .exclude_kernel. So starting with 3.12 "perf list" does not report any hardware events at all on older machines (seen on Rasp-Pi, Pandaboard, Beagleboard, etc). This version of the patch makes changes suggested by Namhyung Kim to check for EACCESS and retry (instead of just dropping the exclude_kernel) so we can properly handle machines where /proc/sys/kernel/perf_event_paranoid is set to 2. Reported-by:
Chad Paradis <chad.paradis@umit.maine.edu> Signed-off-by:
Vince Weaver <vincent.weaver@maine.edu> Acked-by:
-
Jiri Olsa authored
We removed event types from data file in following commits: 6065210d perf tools: Remove event types framework completely 44b3c578 perf tools: Remove event types from perf data file We no longer need this information, because we can get it directly from tracepoints. But we still need to handle PERF_RECORD_HEADER_EVENT_TYPE event for the sake of old perf data files created in pipe mode like: $ perf.3.4 record -o - foo >perf.data $ perf.312 report -i - < perf.data Reported-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
-
Masami Hiramatsu authored
Fix perf-probe not to add offset value twice to uprobe probe address when post processing. The tevs[i].point.address struct member is the address of symbol+offset, but current perf-probe adjusts the point.address by adding the offset. As a result, the probe address becomes symbol+offset+offset. This may cause unexpected code corruption. Urgent fix is needed. Without this fix: --- # ./perf probe -x ./perf dso__load_vmlinux+4 # ./perf probe -l probe_perf:dso__load_vmlinux (on 0x000000000006d2b8) # nm ./perf.orig | grep dso__load_vmlinux\$ 000000000046d0a0 T dso__load_vmlinux --- You can see the given offset is 3 but the actual probed address is dso__load_vmlinux+8. With this fix: --- # ./perf probe -x ./perf dso__load_vmlinux+4 # ./perf probe -l probe_perf:dso__load_vmlinux (on 0x000000000006d2b4) --- Now the problem is fixed. Note: This bug is introduced by commit fb7345bbSigned-off-by:Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: "David A. Long" <dave.long@linaro.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: yrl.pp-manager.tt@hitachi.com Link: http://lkml.kernel.org/r/20140205051858.6519.27314.stgit@kbuild-fedora.yrl.intra.hitachi.co.jpSigned-off-by:
-
- 09 Feb, 2014 7 commits
-
-
Don Zickus authored
A bunch of unknown NMIs have popped up on a Pentium4 recently when booting into a kdump kernel. This was exposed because the watchdog timer went from 60 seconds down to 10 seconds (increasing the ability to reproduce this problem). What is happening is on boot up of the second kernel (the kdump one), the previous nmi_watchdogs were enabled on thread 0 and thread 1. The second kernel only initializes one cpu but the perf counter on thread 1 still counts. Normally in a kdump scenario, the other cpus are blocking in an NMI loop, but more importantly their local apics have the performance counters disabled (iow LVTPC is masked). So any counters that fire are masked and never get through to the second kernel. However, on a P4 the local apic is shared by both threads and thread1's PMI (despite being configured to only interrupt thread1) will generate an NMI on thread0. Because thread0 knows nothing about this NMI, it is seen as an unknown NMI. This would be fine because it is a kdump kernel, strange things happen what is the big deal about a single unknown NMI. Unfortunately, the P4 comes with another quirk: clearing the overflow bit to prevent a stream of NMIs. This is the problem. The kdump kernel can not execute because of the endless NMIs that happen. To solve this, I instrumented the p4 perf init code, to walk all the counters and zero them out (just like a normal reset would). Now when the counters go off, they do not generate anything and no unknown NMIs are seen. I tested this on a P4 we have in our lab. After two or three crashes, I could normally reproduce the problem. Now after 10 crashes, everything continues to boot correctly. Signed-off-by:
Don Zickus <dzickus@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140120154115.GZ25953@redhat.com [ Fixed a stylistic detail. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Don Zickus authored
On a P4 box stressing perf with: ./perf record -o perf.data ./perf stat -v ./perf bench all it was noticed that a slew of unknown NMIs would pop out rather quickly. Painfully debugging this ancient platform, led me to notice cross cpu counter corruption. The P4 machine is special in that it has 18 counters, half are used for cpu0 and the other half is for cpu1 (or all 18 if hyperthreading is disabled). But the splitting of the counters has to be actively managed by the software. In this particular bug, one of the cpu0 specific counters was being used by cpu1 and caused all sorts of random unknown nmis. I am not entirely sure on the corruption path, but what happens is: o perf schedules a group with p4_pmu_schedule_events() o inside p4_pmu_schedule_events(), it notices an hwc pointer is being reused but for a different cpu, so it 'swaps' the config bits and returns the updated 'assign' array with a _new_ index. o perf schedules another group with p4_pmu_schedule_events() o inside p4_pmu_schedule_events(), it notices an hwc pointer is being reused (the same one as above) but for the _same_ cpu [BUG!!], so it updates the 'assign' array to use the _old_ (wrong cpu) index because the _new_ index is in an earlier part of the 'assign' array (and hasn't been committed yet). o perf commits the transaction using the wrong index and corrupts the other cpu The [BUG!!] is because the 'hwc->config' is updated but not the 'hwc->idx'. So the check for 'p4_should_swap_ts()' is correct the first time around but incorrect the second time around (because hwc->config was updated in between). I think the spirit of perf was to not modify anything until all the transactions had a chance to 'test' if they would succeed, and if so, commit atomically. However, P4 breaks this spirit by touching the hwc->config element. So my fix is to continue the un-perf like breakage, by assigning hwc->idx to -1 on swap to tell follow up group scheduling to find a new index. Of course if the transaction fails rolling this back will be difficult, but that is not different than how the current code works. :-) And I wasn't sure how much effort to cleanup the code I should do for a platform that is almost 10 years old by now. Hence the lazy fix. Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Peter Zijlstra authored
Calling printk() from NMI context is bad (TM), so move it to IRQ context. In doing so we slightly change (probably wreck) the debugfs nmi_longest_ns thingy, in that it doesn't update to reflect the longest, nor does writing to it reset the count. Signed-off-by:
-
Peter Zijlstra authored
Calling printk() from NMI context is bad (TM), so move it to IRQ context. This also avoids the problem where the printk() time is measured by the generic NMI duration goo and triggers a second warning. Signed-off-by:
-
Ingo Molnar authored
Refresh the branch to a v3.14-rc base before queueing up new devel patches. Signed-off-by: -
Peter Zijlstra authored
The current code forgets to change the CR4 state on the current CPU. Use on_each_cpu() instead of smp_call_function(). Reported-by:
Mark Davies <junk@eslaf.co.uk> Suggested-by:
-
Peter Zijlstra authored
PPro machines can die hard when PCE gets enabled due to a CPU erratum. The safe way it so disable it by default and keep it disabled. See erratum 26 in: http://download.intel.com/design/archives/processors/pro/docs/24268935.pdfReported-and-Tested-by:
-
- 08 Feb, 2014 6 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrlLinus Torvalds authored
Pull pinctrl fixes from Linus Walleij: "First round of pin control fixes for v3.14: - Protect pinctrl_list_add() with the proper mutex. This was identified by RedHat. Caused nasty locking warnings was rootcased by Stanislaw Gruszka. - Avoid adding dangerous debugfs files when either half of the subsystem is unused: pinmux or pinconf. - Various fixes to various drivers: locking, hardware particulars, DT parsing, error codes" * tag 'pinctrl-v3.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: tegra: return correct error type pinctrl: do not init debugfs entries for unimplemented functionalities pinctrl: protect pinctrl_list add pinctrl: sirf: correct the pin index of ac97_pins group pinctrl: imx27: fix offset calculation in imx_read_2bit pinctrl: vt8500: Change devicetree data parsing pinctrl: imx27: fix wrong offset to ICONFB pinctrl: at91: use locked variant of irq_set_handler -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fix from Thomas Gleixner: "Add a missing Kconfig dependency" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq: Generic irq chip requires IRQ_DOMAIN
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Peter Anvin: "Quite a varied little collection of fixes. Most of them are relatively small or isolated; the biggest one is Mel Gorman's fixes for TLB range flushing. A couple of AMD-related fixes (including not crashing when given an invalid microcode image) and fix a crash when compiled with gcov" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, microcode, AMD: Unify valid container checks x86, hweight: Fix BUG when booting with CONFIG_GCOV_PROFILE_ALL=y x86/efi: Allow mapping BGRT on x86-32 x86: Fix the initialization of physnode_map x86, cpu hotplug: Fix stack frame warning in check_irq_vectors_for_cpu_disable() x86/intel/mid: Fix X86_INTEL_MID dependencies arch/x86/mm/srat: Skip NUMA_NO_NODE while parsing SLIT mm, x86: Revisit tlb_flushall_shift tuning for page flushes except on IvyBridge x86: mm: change tlb_flushall_shift for IvyBridge x86/mm: Eliminate redundant page table walk during TLB range flushing x86/mm: Clean up inconsistencies when flushing TLB ranges mm, x86: Account for TLB flushes only when debugging x86/AMD/NB: Fix amd_set_subcaches() parameter type x86/quirks: Add workaround for AMD F16h Erratum792 x86, doc, kconfig: Fix dud URL for Microcode data
-
git://github.com/kleikamp/linux-shaggyLinus Torvalds authored
Pull jfs fix from David Kleikamp: "Fix regression" * tag 'jfs-3.14-rc2' of git://github.com/kleikamp/linux-shaggy: jfs: fix generic posix ACL regression
-
Dave Kleikamp authored
I missed a couple errors in reviewing the patches converting jfs to use the generic posix ACL function. Setting ACL's currently fails with -EOPNOTSUPP. Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Reported-by:
Michael L. Semon <mlsemon35@gmail.com> Reviewed-by:
Christoph Hellwig <hch@lst.de>
-
Richard Weinberger authored
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM to bypass build failures. drivers/built-in.o: In function `dw_wdt_drv_probe': drivers/watchdog/dw_wdt.c:302: undefined reference to `devm_ioremap_resource' Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be>
-
