Skip to content
GitLab
  1. Feb 22, 2012
  3. Feb 21, 2012
  5. Feb 17, 2012
  7. Feb 15, 2012
  9. Feb 14, 2012
  11. Feb 13, 2012
  13. Feb 11, 2012
  15. Feb 09, 2012
    • David Ahern's avatar
      perf record: No build id option fails · d3665498
      David Ahern authored 
      A recent refactoring of perf-record introduced the following:

perf record -a -B
Couldn't generating buildids. Use --no-buildid to profile anyway.
sleep: Terminated

I believe the triple negative was meant to be only a double negative.
:-) While I'm there, fixed the grammar on the error message.

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1328567272-13190-1-git-send-email-dsahern@gmail.com


Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      d3665498
    • Stephane Eranian's avatar
      perf tools: fix endianness detection in perf.data · 73323f54
      Stephane Eranian authored 
      

The current version of perf detects whether or not the perf.data file is
written in a different endianness using the attr_size field in the
header of the file. This field represents sizeof(struct perf_event_attr)
as known to perf record. If the sizes do not match, then perf tries the
byte-swapped version. If they match, then the tool assumes a different
endianness.

The issue with the approach is that it assumes the size of
perf_event_attr always has to match between perf record and perf report.
However, the kernel perf_event ABI is extensible.  New fields can be
added to struct perf_event_attr. Consequently, it is not possible to use
attr_size to detect endianness.

This patch takes another approach by using the magic number written at
the beginning of the perf.data file to detect endianness. The magic
number is an eight-byte signature.  It's primary purpose is to identify
(signature) a perf.data file. But it could also be used to encode the
endianness.

The patch introduces a new value for this signature. The key difference
is that the signature is written differently in the file depending on
the endianness. Thus, by comparing the signature from the file with the
tool's own signature it is possible to detect endianness. The new
signature is "PERFILE2".

Backward compatiblity with existing perf.data file is ensured.

Tested-by: default avatarDavid Ahern <dsahern@gmail.com>
Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Arun Sharma <asharma@fb.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Lin Ming <ming.m.lin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roberto Agostino Vitillo <ravitillo@lbl.gov>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Vince Weaver <vweaver1@eecs.utk.edu>
Link: http://lkml.kernel.org/r/1328187288-24395-15-git-send-email-eranian@google.com


Signed-off-by: default avatarStephane Eranian <eranian@google.com>
Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      73323f54
  17. Feb 07, 2012
    • Borislav Petkov's avatar
      x86/sched/perf/AMD: Set sched_clock_stable · c98fdeaa
      Borislav Petkov authored 
      

Stephane Eranian reported that doing a scheduler latency
measurements with perf on AMD doesn't work out as expected due
to the fact that the sched_clock() granularity is too coarse,
i.e. done in jiffies due to the sched_clock_stable not set,
which, if set, would mean that we get to use the TSC as sample
source which would give us much higher precision.

However, there's no reason not to set sched_clock_stable on AMD
because all families from F10h and upwards do have an invariant
TSC and have the CPUID flag to prove (CPUID_8000_0007_EDX[8]).

Make it so, #1.

Signed-off-by: default avatarBorislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@amd64.org>
Cc: Venki Pallipadi <venki@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Link: http://lkml.kernel.org/r/20120206132546.GA30854@quad


[ Should any non-standard system break the TSC, we should
  mark them so explicitly, in their platform init handler, or
  in a DMI quirk. ]
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c98fdeaa
    • Ingo Molnar's avatar
      Merge tag 'perf-core-for-mingo' of... · 52fce956
      Ingo Molnar authored 
      Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux

 into perf/core

perf/core fixes and improvements.

Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      52fce956
    • Ingo Molnar's avatar
      Merge tag 'v3.3-rc2' into perf/core · 290436c9
      Ingo Molnar authored 
      

Linux 3.3-rc2

Pick up the latest fixes.

Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      290436c9
    • Namhyung Kim's avatar
      perf stat: Align scaled output of cpu-clock · 9dac6a29
      Namhyung Kim authored 
      The output of cpu-clock event is controlled in nsec_printout(),
but its alignment was broken:

 Performance counter stats for 'sleep 1':

         6,038,774 instructions              #    0.00  insns per cycle
               180 faults                    #    0.007 K/sec                   [99.95%]
         1,282,201 branches                  #    0.053 M/sec                   [99.84%]
      24126.221811 cpu-clock                 [99.62%]
      24121.689540 task-clock                #   24.098 CPUs utilized           [99.52%]

       1.001001017 seconds time elapsed

This patch fixes this:

 Performance counter stats for 'sleep 1':

        13,540,843 instructions              #    0.00  insns per cycle
               180 faults                    #    0.007 K/sec                   [99.94%]
         2,875,386 branches                  #    0.119 M/sec                   [99.82%]
      24144.221137 cpu-clock                                                    [99.61%]
      24133.515366 task-clock                #   24.109 CPUs utilized           [99.52%]

       1.001020946 seconds time elapsed

Cc: Ingo Molnar <mingo@elte.hu>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1328514285-26232-2-git-send-email-namhyung.kim@lge.com


Signed-off-by: default avatarNamhyung Kim <namhyung.kim@lge.com>
Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      9dac6a29