24 Apr, 2017

1 commit


21 Apr, 2017

4 commits


20 Apr, 2017

30 commits


17 Apr, 2017

1 commit

  • …nux/kernel/git/acme/linux into perf/core

    Pull perf/core improvements and fixes Arnaldo Carvalho de Melo:

    User visible changes:

    - Fix 'perf stat' bug in handling events in error state (Stephane Eranian)

    Documentation changes:

    - Add usage of --no-syscalls in 'perf trace' man page (Ravi Bangoria)

    Infrastructure changes:

    - Pass PYTHON config to feature detection (David Carrillo-Cisneros)

    - Disable JVMTI if no ELF support available (David Carrillo-Cisneros)

    - Fix feature detection redefinion of build flags (David Carrillo-Cisneros)

    - Hint missing file when tool tips fail to load (David Carrillo-Cisneros)

    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

    Ingo Molnar
     

14 Apr, 2017

3 commits

  • Spurious NMIs will be observed with the following command:

    while :; do
    perf record -bae "cpu/umask=0x01,event=0xcd,ldlat=0x80/pp"
    -e "cpu/umask=0x03,event=0x0/"
    -e "cpu/umask=0x02,event=0x0/"
    -e cycles,branches,cache-misses
    -e cache-references -- sleep 10
    done

    The bug was introduced by commit:

    8077eca079a2 ("perf/x86/pebs: Add workaround for broken OVFL status on HSW+")

    That commit clears the status bits for the counters used for PEBS
    events, by masking the whole 64 bits pebs_enabled. However, only the
    low 32 bits of both status and pebs_enabled are reserved for PEBS-able
    counters.

    For status bits 32-34 are fixed counter overflow bits. For
    pebs_enabled bits 32-34 are for PEBS Load Latency.

    In the test case, the PEBS Load Latency event and fixed counter event
    could overflow at the same time. The fixed counter overflow bit will
    be cleared by mistake. Once it is cleared, the fixed counter overflow
    never be processed, which finally trigger spurious NMI.

    Correct the PEBS enabled mask by ignoring the non-PEBS bits.

    Signed-off-by: Kan Liang
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Alexander Shishkin
    Cc: Arnaldo Carvalho de Melo
    Cc: Jiri Olsa
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: Thomas Gleixner
    Cc: Vince Weaver
    Fixes: 8077eca079a2 ("perf/x86/pebs: Add workaround for broken OVFL status on HSW+")
    Link: http://lkml.kernel.org/r/1491333246-3965-1-git-send-email-kan.liang@intel.com
    Signed-off-by: Ingo Molnar

    Kan Liang
     
  • Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • When the perf_branch_entry::{in_tx,abort,cycles} fields were added,
    intel_pmu_lbr_read_32() wasn't updated to initialize them.

    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-kernel@vger.kernel.org
    Cc:
    Fixes: 135c5612c460 ("perf/x86/intel: Support Haswell/v4 LBR format")
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

13 Apr, 2017

1 commit

  • In https://lkml.org/lkml/2017/2/2/16 I reported a build error that I
    believed was caused by wrong uapi includes. The synthom was fixed by
    Arnaldo in:

    commit 2f7db5557994 ("perf tools: Fix include of linux/mman.h")

    but I was wrong attributing the problem to the uapi include.

    The root cause was that I was using ARCH=x86_64, hence using the wrong
    uapi include path. This explains why no one else ran into this build
    problem.

    Signed-off-by: David Carrillo-Cisneros
    Acked-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: Andi Kleen
    Cc: He Kuang
    Cc: Masami Hiramatsu
    Cc: Paul Turner
    Cc: Peter Zijlstra
    Cc: Simon Que
    Cc: Stephane Eranian
    Cc: Wang Nan
    Link: http://lkml.kernel.org/r/20170412064919.92449-8-davidcc@google.com
    Signed-off-by: Arnaldo Carvalho de Melo

    David Carrillo-Cisneros