1. 20 11月, 2012 1 次提交
    • D
      perf: Make perf build for x86 with UAPI disintegration applied · d2709c7c
      David Howells 提交于
      Make perf build for x86 once the UAPI disintegration patches for that arch
      have been applied by adding the appropriate -I flags - in the right order -
      and then converting some #includes that use ../.. notation to find main kernel
      headerfiles to use <asm/foo.h> and <linux/foo.h> instead.
      
      Note that -Iarch/foo/include/uapi is present _before_ -Iarch/foo/include.
      This makes sure we get the userspace version of the pt_regs struct.  Ideally,
      we wouldn't have the latter -I flag at all, but unfortunately we want
      asm/svm.h and asm/vmx.h in builtin-kvm.c and these aren't part of the UAPI -
      at least not for x86.  I wonder if the bits outside of the __KERNEL__ guards
      *should* be transferred there.
      
      I note also that perf seems to do its dependency handling manually by listing
      all the header files it might want to use in LIB_H in the Makefile.  Can this
      be changed to use -MD?
      
      Note that to do make this work, we need to export and UAPI disintegrate
      linux/hw_breakpoint.h, which I think should've been exported previously so that
      perf can access the bits.  We have to do this in the same patch to maintain
      bisectability.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      d2709c7c
  2. 30 10月, 2012 2 次提交
  3. 23 10月, 2012 1 次提交
  4. 22 10月, 2012 1 次提交
    • L
      perf tools: do not flush maps on COMM for perf report · 9fdbf671
      Luigi Semenzato 提交于
      This fixes a long-standing bug caused by the lack of separate COMM and EXEC
      record types, which makes "perf report" lose track of symbols when a process
      renames itself.
      
      With this fix (suggested by Stephane Eranian), a COMM (rename) no longer
      flushes the maps, which is the correct behavior.  An EXEC also no longer
      flushes the maps, but this doesn't matter because as new mappings are created
      (for the executable and the libraries) the old mappings are automatically
      removed.  This is not by accident: the functionality is necessary because DLLs
      can be explicitly loaded at any time with dlopen(), possibly on top of existing
      text, so "perf report" handles correctly the clobbering of new mappings on top
      of old ones.
      
      An alternative patch (which I proposed earlier) would be to introduce a
      separate PERF_RECORD_EXEC type, but it is a much larger change (about 300
      lines) and is not necessary.
      Signed-off-by: NLuigi Semenzato <semenzato@chromium.org>
      Tested-by: NStephane Eranian <eranian@google.com>
      Acked-by: NStephane Eranian <eranian@google.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Olof Johansson <olofj@chromium.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Sonny Rao <sonnyrao@chromium.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Stephen Wilson <wilsons@start.ca>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Vasiliy Kulikov <segoon@openwall.com>
      Link: http://lkml.kernel.org/r/1345585940-6497-1-git-send-email-semenzato@chromium.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9fdbf671
  5. 20 10月, 2012 1 次提交
  6. 17 10月, 2012 4 次提交
  7. 16 10月, 2012 1 次提交
    • D
      perf tool: Precise mode requires exclude_guest · 1342798c
      David Ahern 提交于
      Summary of events per Peter:
      
        "Intel PEBS in VT-x context uses the DS address as a guest linear address,
        even though its programmed by the host as a host linear address. This
        either results in guest memory corruption and or the hardware faulting and
        'crashing' the virtual machine.  Therefore we have to disable PEBS on VT-x
        enter and re-enable on VT-x exit, enforcing a strict exclude_guest.
      
        AMB IBS does work but doesn't currently support exclude_* at all,
        setting an exclude_* bit will make it fail."
      
      This patch handles userspace perf command, setting the exclude_guest
      attribute if precise mode is requested, but only if a user has not
      specified a request for guest or host only profiling (G or H attribute).
      
      Kernel side AMD currently ignores all exclude_* bits, so there is no impact
      to existing IBS code paths. Robert Richter has a patch where IBS code will
      return EINVAL if an exclude_* bit is set. When this goes in it means use
      of :p on AMD with IBS will first fail with EINVAL (because exclude_guest
      will be set). Then the existing fallback code within perf will unset
      exclude_guest and try again. The second attempt will succeed if the CPU
      supports IBS profiling.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Acked-by: NRobert Richter <robert.richter@amd.com>
      Tested-by: NRobert Richter <robert.richter@amd.com>
      Reviewed-by: NRobert Richter <robert.richter@amd.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Richter <robert.richter@amd.com>
      Link: http://lkml.kernel.org/r/1347569955-54626-2-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1342798c
  8. 15 10月, 2012 1 次提交
  9. 13 10月, 2012 1 次提交
  10. 11 10月, 2012 1 次提交
  11. 09 10月, 2012 1 次提交
  12. 05 10月, 2012 9 次提交
  13. 03 10月, 2012 8 次提交
  14. 29 9月, 2012 1 次提交
  15. 27 9月, 2012 7 次提交