Hello,
I have released another version of the perfmon new code base package.
This version of the kernel patch is relative to 2.6.20.
This new kernel patch includes the following new features and
bug fixes:
- first cut at supporting Oprofile on i386 and x86-64 architectures
-
Andrew,
On Tue, Feb 13, 2007 at 02:05:33PM -0800, Andrew Morton wrote:
On Tue, 13 Feb 2007 10:48:39 -0800 Stephane Eranian [EMAIL PROTECTED]
wrote:
I have released another version of the perfmon new code base package.
Can we have a bug push to get this merged up please?
Could you
Will,
On Wed, Feb 14, 2007 at 12:05:31PM -0500, William Cohen wrote:
The oprofile patch should be made against the oprofile cvs rather than
the 0.9.2 tarball. There are some files that the patch touches that are
created by the autogen.sh.
The oprofile patch doesn't build if things are
Andi,
On Wed, Feb 14, 2007 at 12:20:56AM +0100, Andi Kleen wrote:
Andrew Morton [EMAIL PROTECTED] writes:
On Tue, 13 Feb 2007 10:48:39 -0800 Stephane Eranian [EMAIL PROTECTED]
wrote:
I have released another version of the perfmon new code base package.
Can we have a bug push
. Core 2
Duo).
This allows PEBS to work when the NMI watchdog is active.
signed-off-by: stephane eranian [EMAIL PROTECTED]
diff -urNp --exclude=.git linux-2.6.20.orig/arch/i386/kernel/nmi.c
linux-2.6.20.base/arch/i386/kernel/nmi.c
--- linux-2.6.20.orig/arch/i386/kernel/nmi.c2007-02-04
to work when the NMI watchdog is active.
signed-off-by: stephane eranian [EMAIL PROTECTED]
diff -urNp --exclude=.git linux-2.6.20.orig/arch/x86_64/kernel/nmi.c
linux-2.6.20.base/arch/x86_64/kernel/nmi.c
--- linux-2.6.20.orig/arch/x86_64/kernel/nmi.c 2007-02-04 10:44:54.0
-0800
+++ linux
Andi,
On Sun, Feb 18, 2007 at 05:56:05PM +0100, Andi Kleen wrote:
On Saturday 17 February 2007 17:06, Stephane Eranian wrote:
Hello,
This patch against 2.6.20
Please always submit against mainline:
Isn't 2.6.20 the latest mainline?
patching file arch/i386/kernel/nmi.c
Hunk #1
(e.g. Core 2
Duo).
This allows PEBS to work when the NMI watchdog is active.
signed-off-by: stephane eranian [EMAIL PROTECTED]
diff -urNp --exclude=.git linux-2.6.20.orig/arch/i386/kernel/nmi.c
linux-2.6.20.base/arch/i386/kernel/nmi.c
--- linux-2.6.20.orig/arch/i386/kernel/nmi.c2007
supporting the Intel architectural perfmon (e.g. Core 2
Duo).
This allows PEBS to work when the NMI watchdog is active.
signed-off-by: stephane eranian [EMAIL PROTECTED]
diff -urNp --exclude=.git linux-2.6.20.orig/arch/x86_64/kernel/nmi.c
linux-2.6.20.base/arch/x86_64/kernel/nmi.c
--- linux
Hello,
I ran into an issue with perfmon where I ended up calling
kmalloc() with a size of zero. To my surprise, this did
not return NULL but a valid data address.
I am wondering if this is a property of kmalloc() or simply
a bug. It is the case that the __kmalloc() code does not
check for zero
Hi,
On Sun, Mar 25, 2007 at 06:30:34PM +0200, Folkert van Heusden wrote:
I'd say feature, glibc's malloc also returns an address on
malloc(0).
This is implementation defined-the standard allows for return of either
null or an address.
Entirely for entertainment: AIX (5.3) returns
Venki,
On Tue, Apr 10, 2007 at 05:15:14PM -0700, Venki Pallipadi wrote:
x86-64 expects all idle handlers to enable interrupts before returning
from
idle handler. This is due to enter_idle(), exit_idle() races. Make
cpuidle_idle_call() confirm to this when there is no pm_idle_old.
Andi,
On Wed, Apr 11, 2007 at 12:39:05PM +0200, Andi Kleen wrote:
The next kernel patch for Perfmon will not make use of the idle notification
anymore on any platform.
What do you use instead?
Nothing. I was using the idle notifier as a way to stop monitoring on entry and
restart on
nick,
On Tue, Feb 20, 2007 at 03:18:56PM +0100, Nick Piggin wrote:
From: Nick Piggin [EMAIL PROTECTED]
Perfmon associates vmalloc()ed memory with a file descriptor, and installs
a vma mapping that memory. Unfortunately, the vm_file field is not filled in,
so processes with mappings to that
Nick,
On Tue, Feb 20, 2007 at 04:08:45PM +0100, Nick Piggin wrote:
On Tue, Feb 20, 2007 at 06:34:54AM -0800, Stephane Eranian wrote:
nick,
On Tue, Feb 20, 2007 at 03:18:56PM +0100, Nick Piggin wrote:
From: Nick Piggin [EMAIL PROTECTED]
Perfmon associates vmalloc()ed memory
Hi,
On Mon, Feb 26, 2007 at 07:51:19AM -0800, Linus Torvalds wrote:
On Mon, 26 Feb 2007, Jiri Slaby wrote:
Ok, this commit is the culprit:
Commit: 2ff2d3d74705d34ab71b21f54634fcf50d57bdd5
Author: Stephane Eranian [EMAIL PROTECTED] Tue, 13 Feb 2007 13:26:22 +0100
[PATCH
Linus,
On Mon, Feb 26, 2007 at 09:10:22AM -0800, Linus Torvalds wrote:
Side note: this patch adds several function calls (4), several additional
L1 cache touches and a generally inefficient code path to *every single
interrupt that exits from the idle poll*, not to mention the extra
Hello,
I have come across an issue with a monitoring using the
hardware debug registers on ia64/i386/x86-64.
It seems that the way debug registers are inherited across fork
differs between ia-64 and i386/x86-64. On ia-64, the debug registers
are NEVER inherited in the child. The copy_thread()
Alan,
On Wed, Feb 28, 2007 at 07:01:17PM -0500, Alan Stern wrote:
On Wed, 28 Feb 2007, Roland McGrath wrote:
It is true that debug registers are inherited by fork and clone.
I am 99% sure that this was never specifically intended, but it
has been this way for a long time (since 2.4 at
Andrew,
On Thu, Mar 01, 2007 at 04:47:42PM -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 15:32:22 +0100
Uwe Bugla [EMAIL PROTECTED] wrote:
Hi folks,
this patch fixes the floppy mount bug (i. e. regression) in kernel
2.6.21-rc1. It was inspired by Stephane Eranian. It was tested
Andi,
On Mon, Mar 05, 2007 at 06:25:16PM +0100, Andi Kleen wrote:
On Tuesday 27 February 2007 00:51, Stephane Eranian wrote:
I have come across an issue with a monitoring using the
hardware debug registers on ia64/i386/x86-64.
It seems that the way debug registers are inherited
Hello,
It seems that the kernel does not expose the Front-Side Bus (FSN) Clock
speed to user applications. I found code in the kernel dealing with
frequency scaling that extracts the information for x86 processors but
the value is never exposed.
Knowledge the the FSB speed is very useful to
Andi,
On Sat, Mar 31, 2007 at 04:31:29AM +0200, Andi Kleen wrote:
Stephane Eranian [EMAIL PROTECTED] writes:
It seems that the kernel does not expose the Front-Side Bus (FSN) Clock
speed to user applications.
You mean the APIC timer frequency which happens to match the FSB
on some
Len,
On Mon, Apr 02, 2007 at 12:14:43PM -0400, Lennart Sorensen wrote:
On Sat, Mar 31, 2007 at 12:18:32AM -0800, Stephane Eranian wrote:
Well, I am talking about the bus that connects the processor socket to the
chipset on Intel machines. On Intel Core 2 Duo (aka Woodcrest), you have
2
Hello,
On Tue, Nov 13, 2007 at 10:35:11AM -0500, William Cohen wrote:
Robert Richter wrote:
On 10.11.07 21:32:39, Andi Kleen wrote:
It would be really good to extract a core perfmon and start with
that and then add stuff as it makes sense.
e.g. core perfmon could be something simple
Hello,
On Tue, Nov 13, 2007 at 04:17:18PM +0100, Robert Richter wrote:
On 10.11.07 21:32:39, Andi Kleen wrote:
It would be really good to extract a core perfmon and start with
that and then add stuff as it makes sense.
e.g. core perfmon could be something simple like just support
to
Will,
On Tue, Nov 13, 2007 at 01:33:55PM -0500, William Cohen wrote:
The oprofile module can setup a handler for PMU interrupts. This is done in
archi/x86/oprofile/nmi_int:nmi_cpu_setup(). Other modules could do the
same. However, it bumps what ever was using the nmi/pmu off, then
Greg,
On Tue, Nov 13, 2007 at 10:59:24AM -0800, Greg KH wrote:
On Tue, Nov 13, 2007 at 10:47:45AM -0800, Philip Mucci wrote:
Hi folks,
Well, I can say the mood here at supercomputing'07 is pretty somber in
regards to the latest exchange of messages regarding the perfmon patches.
Andi.
On Tue, Nov 13, 2007 at 10:29:02PM +0100, Andi Kleen wrote:
On Tue, Nov 13, 2007 at 01:13:45PM -0800, Stephane Eranian wrote:
Oprofile does not setup the PMU interrupt. It builds on top of the NMI
watchdog
setup.
Oprofile works without the NMI watchdog too, but it just happens
Andi,
On Tue, Nov 13, 2007 at 10:50:56PM +0100, Andi Kleen wrote:
Yes, horribly more complicated because of locking issues within perfmon.
As soon as you expose a file descriptor, you need some locking to prevent
multiple user threads (malicious or not) to compete to access the PMU state.
Andi,
On Tue, Nov 13, 2007 at 11:25:34PM +0100, Andi Kleen wrote:
On Tue, Nov 13, 2007 at 02:22:34PM -0800, Stephane Eranian wrote:
Andi,
On Tue, Nov 13, 2007 at 10:50:56PM +0100, Andi Kleen wrote:
Yes, horribly more complicated because of locking issues within perfmon.
As soon
Andi,
On Wed, Nov 14, 2007 at 03:07:02AM +0100, Andi Kleen wrote:
[dropped all these bouncing email lists. Adding closed lists to public
cc lists is just a bad idea]
Just want to make sure perfmon2 users participate in this discussion.
int
main(int argc, char **argv)
{
int
Hello,
On Wed, Nov 14, 2007 at 10:39:24PM +1100, Paul Mackerras wrote:
Christoph Hellwig writes:
int pfm_read_pmds(int fd, pfarg_pmd_t *pmds, int n)
This is basically a read(2) (or for other syscalls a write) on something
else than the file descriptor provided to the system call.
On Wed, Nov 14, 2007 at 10:44:56PM +1100, Paul Mackerras wrote:
David Miller writes:
This is my impression too, all of the things being done with
a slew of system calls would be better served by real special
files and appropriate fops.
Special files and fops really only work well if
Andi,
On Wed, Nov 14, 2007 at 01:38:38PM +0100, Andi Kleen wrote:
Christoph Hellwig [EMAIL PROTECTED] writes:
I've done this a gazillion times before, so maybe instead of beeing a lazy
bastard you could look up mailinglist archive. It's not like this is the
first discussion of perfmon.
On Wed, Nov 14, 2007 at 10:44:20AM -0500, William Cohen wrote:
Andi Kleen wrote:
One approach does not prevent the other. Assuming you allow cr4.pce, then
nothing prevents
a self-monitoring thread from reading the counters directly. You'll just
get the
lower 32-bit of it. So if you read
Thomas,
On Fri, Nov 09, 2007 at 07:40:31PM +0100, Thomas Gleixner wrote:
On Fri, 9 Nov 2007, Peter Zijlstra wrote:
It looks like a solution would be to change the implementation of
timeout-based switching to use HR timers instead. Similar to what is
done for ITIMER_REAL and
Andi,
On Wed, Nov 14, 2007 at 03:24:11PM +0100, Andi Kleen wrote:
On Wed, Nov 14, 2007 at 05:09:09AM -0800, Stephane Eranian wrote:
Partially true. The file descriptor becomes really useful when you sample.
You leverage the file descriptor to receive notifications of counter
overflows
Hi,
On Thu, Nov 15, 2007 at 12:11:10PM +1100, Paul Mackerras wrote:
David Miller writes:
From: Paul Mackerras [EMAIL PROTECTED]
Date: Thu, 15 Nov 2007 10:12:22 +1100
*I* never had a problem with a few extra system calls. I don't
understand why you (apparently) do.
We're
Hello,
On Wed, Nov 14, 2007 at 08:20:22PM -0800, dean gaudet wrote:
On Wed, 14 Nov 2007, Andi Kleen wrote:
Later a syscall might be needed with event multiplexing, but that seems
more like a far away non essential feature.
actually multiplexing is the main feature i am in need of. there
Andi,
On Fri, Nov 16, 2007 at 04:15:56PM +0100, Andi Kleen wrote:
My impression so far is that you're not quite sure what you want,
otherwise you would be more concrete.
- A feature which was dropped earlier by Stefane (only to satiate
LKML), we consider
very important. Allowing one
Andi,
On Fri, Nov 16, 2007 at 05:28:13PM +0100, Andi Kleen wrote:
On Fri, Nov 16, 2007 at 08:00:56AM -0800, Stephane Eranian wrote:
No, he is talking about something similar to what was in perfctr.
The kernel emulates 64-bit counters in software and that is you
get back when you read
Will,
On Fri, Nov 16, 2007 at 12:13:07PM -0500, William Cohen wrote:
Andi Kleen wrote:
On Fri, Nov 16, 2007 at 08:00:56AM -0800, Stephane Eranian wrote:
No, he is talking about something similar to what was in perfctr.
The kernel emulates 64-bit counters in software and that is you
get back
David,
On Mon, Nov 19, 2007 at 05:08:43AM -0800, David Miller wrote:
Instead of blabbering further about this topic, I decided to put my
code where my mouth is and spent the weekend porting the perfmon2
kernel bits, and the user bits (libpfm and pfmon) to sparc64.
I appreciate your
Paul,
On Tue, Nov 20, 2007 at 08:43:32AM +1100, Paul Mackerras wrote:
David Miller writes:
As a result I've found that perfmon2 is quite nice and allows
incredibly useful and powerful tools to be written. The syscalls
aren't that bad and really I see not reason to block it's inclusion.
Hi,
and it seems like this patch and perfmon2 are going to have to
live with
each other... since they both require the use of the DS save area...
Hmmm, this might require some synchronization between those two.
Do you know how (accesses to) MSR's are managed by the kernel?
There is a
Hello,
On Fri, Nov 09, 2007 at 07:40:31PM +0100, Thomas Gleixner wrote:
On Fri, 9 Nov 2007, Peter Zijlstra wrote:
On Fri, 2007-11-09 at 02:44 -0800, Stephane Eranian wrote:
Hello,
We have identified a conflict between TICKLESS (CONFIG_NO_HZ) and
the current perfmon2
Hello,
A few weeks back, I mentioned that I would post some
interesting problems that I have encountered while
implementing perfmon and for which I am still looking
for better solutions.
Here is one that I would like to solve right now and
for which I am interested in your comments.
One of the
Charles,
On Fri, Dec 14, 2007 at 02:12:17PM -0500, Frank Ch. Eigler wrote:
Stephane Eranian [EMAIL PROTECTED] writes:
[...] AFAIK, there is no single call to stop T1 and wait until it
is completely off the CPU, unless we go through the (internal)
ptrace interface.
The utrace code
Jeff,
On Tue, Oct 23, 2007 at 07:09:08PM -0400, Jeff Garzik wrote:
By deleting unused code, this makes perfmon irq handling more efficient,
as well as reducing code size.
* remove unused pfm_install_alt_pmu_interrupt()
* remove unused pfm_remove_alt_pmu_interrupt()
I have not problem
Hello,
I have released another version of the perfmon new code base package.
This version of the kernel patch is relative to 2.6.23. This is the first
release based on the perfmon git tree from kernel.org. The structure of
the package has changed, only one diff file to apply now.
This new patch
On Mon, Oct 29, 2012 at 10:16 PM, Andi Kleen a...@linux.intel.com wrote:
Why do you need to replace the whole table?
Because I am extending them with one or two events based on cpu
model. That was the easiest way of doing this instead of playing
some kind of malloc+copy trick.
I did
Arnaldo,
A long time ago, I brought up the issue of perf failing to resolve
data symbols despite having the MAP__VARIABLE map type.
Now that I have posted the PEBS-LL patch series, there is a test
case to debug this.
I looked again at it today. Start from ip__resolve_data() in my patchset.
IT
On Tue, Oct 30, 2012 at 9:29 PM, Stephane Eranian eran...@google.com wrote:
Arnaldo,
A long time ago, I brought up the issue of perf failing to resolve
data symbols despite having the MAP__VARIABLE map type.
Now that I have posted the PEBS-LL patch series, there is a test
case to debug
On Wed, Oct 31, 2012 at 6:21 AM, Namhyung Kim namhy...@kernel.org wrote:
On Mon, 29 Oct 2012 16:15:48 +0100, Stephane Eranian wrote:
This patch adds support for PEBS Precise Store
which is available on Intel Sandy Bridge and
Ivy Bridge processors.
To use Precise store, the proper PEBS event
On Wed, Oct 31, 2012 at 6:51 AM, Namhyung Kim namhy...@kernel.org wrote:
On Mon, 29 Oct 2012 16:15:49 +0100, Stephane Eranian wrote:
This patch adds the sorting and histogram support
functions to enable profiling of memory accesses.
The following sorting orders are added:
- symbol_daddr
On Wed, Oct 31, 2012 at 7:57 AM, Namhyung Kim namhy...@kernel.org wrote:
On Mon, 29 Oct 2012 16:15:52 +0100, Stephane Eranian wrote:
This new command is a wrapper on top of perf record and
perf report to make it easier to configure for memory
access profiling.
So this new command will be run
0.14% noploop [kernel.kallsyms] [k] lock_acquire
Signed-off-by: Stephane Eranian eran...@google.com
---
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 9ea3854..211a9cb 100644
--- a/tools/perf/builtin
Hi,
I don't understand why the local variable box needs to
be declared static here:
static struct intel_uncore_box *
uncore_pmu_to_box(struct intel_uncore_pmu *pmu, int cpu)
{
static struct intel_uncore_box *box;
box = *per_cpu_ptr(pmu-box, cpu);
if (box)
On Tue, Sep 25, 2012 at 2:01 PM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
On Tue, 2012-09-25 at 15:42 +0400, Cyrill Gorcunov wrote:
Guys, letme re-read this whole mail thread first since I have no clue
what this remapping about ;)
x86_setup_perfctr() / set_ext_hw_attr() have special
On Wed, Sep 26, 2012 at 7:50 AM, David Ahern dsah...@gmail.com wrote:
I like the idea, but can't checkout the patch - does not apply to Arnaldo's
latest perf/core branch. mind rebasing?
It's against tip-master.
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Any comment on this patch set?
This is an important improvement for any system-wide measurement.
On Thu, Sep 13, 2012 at 4:10 PM, Stephane Eranian eran...@google.com wrote:
The current scheme of using the timer tick was fine
for per-thread events. However, it was causing
bias issues in system
On Fri, Sep 28, 2012 at 7:49 AM, Namhyung Kim namhy...@kernel.org wrote:
Hi Frederic,
On Fri, 28 Sep 2012 01:01:48 +0200, Frederic Weisbecker wrote:
When Arun was working on this, I asked him to explore if it could make sense
to reuse
the -b, --branch-stack perf report option. Because
Hi,
I am writing a little test program for the perf_event API which is using
hardcoded events. Some of those events (SNBEP uncore events) require
a value for config1. I was naively assuming, one could simply do:
struct perf_event_attr attr = { .config = 0x1234, .config1 = 0x456 };
However this
On Fri, Oct 5, 2012 at 1:01 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2012-10-05 at 12:36 +0200, Stephane Eranian wrote:
struct perf_event_attr attr = { .config = 0x1234, .config1 = 0x456 };
Does anyone have a better solution to propose?
struct perf_event_attr attr
Ensure we grab the weight from raw sample struct
and that we can dump it via perf report -D.
Signed-off-by: Stephane Eranian eran...@google.com
---
tools/perf/util/event.h |1 +
tools/perf/util/evsel.c |5 +
tools/perf/util/session.c |3 +++
3 files changed, 9 insertions
Was missing from current code yet PERF_SAMPLE_ADDR has
been present for a long time. Needed for PEBS-LL mode.
Signed-off-by: Stephane Eranian eran...@google.com
---
tools/perf/util/session.c |4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/util/session.c b/tools/perf/util
-loads. It export the right event
encoding based on the host CPU and can be used directly
by the perf tool.
Loosely based on Intel's Lin Ming patch posted on LKML
in July 2011.
Signed-off-by: Stephane Eranian eran...@google.com
---
arch/x86/include/asm/msr-index.h |1 +
arch/x86/kernel
.
Signed-off-by: Stephane Eranian eran...@google.com
---
arch/x86/kernel/cpu/perf_event.h |5 +++
arch/x86/kernel/cpu/perf_event_intel.c|2 ++
arch/x86/kernel/cpu/perf_event_intel_ds.c | 49 +++--
3 files changed, 54 insertions(+), 2 deletions(-)
diff
, then
the mapping is executable.
Signed-off-by: Stephane Eranian eran...@google.com
---
include/uapi/linux/perf_event.h |1 +
kernel/events/core.c|3 +++
2 files changed, 4 insertions(+)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index
Leverages the PERF_RECORD_MISC_MMAP_DATA bit in
the RECORD_MMAP record header. When the bit is set
then the mapping type is set to MAP__VARIABLE.
Signed-off-by: Stephane Eranian eran...@google.com
---
tools/perf/util/machine.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion
Add the -l option to perf record to enable sampling
access cost sampling.
Data address sampling is obtained via the -d option.
Signed-off-by: Stephane Eranian eran...@google.com
---
tools/perf/builtin-record.c |2 ++
tools/perf/perf.h |1 +
tools/perf/util/evsel.c |6
This new command is a wrapper on top of perf record and
perf report to make it easier to configure for memory
access profiling.
To record loads:
$ perf mem -t load rec .
To record stores:
$ perf mem -t store rec .
To get the report:
$ perf mem -t load rep
Signed-off-by: Stephane
This patch adds the --mem-mode option to perf report.
This mode requires a perf.data file created with memory
access samples.
Signed-off-by: Stephane Eranian eran...@google.com
---
tools/perf/builtin-report.c | 131 +--
1 file changed, 127 insertions
- tlb : TLB access
- mem : memory level of the access (L1, L2, L3, RAM, ...)
- snoop: access snoop mode
Signed-off-by: Stephane Eranian eran...@google.com
---
tools/perf/util/event.h |1 +
tools/perf/util/evsel.c |4 +
tools/perf/util/hist.c| 66 -
tools/perf/util
Make the PEBS Load Latency threshold register layout
and encoding visible to user level tools.
Signed-off-by: Stephane Eranian eran...@google.com
---
arch/x86/kernel/cpu/perf_event_intel.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch
the data associated with the sampled instruction
come from. Information is stored in a perf_mem_dsrc
structure. It contains opcode, mem level, tlb, snoop,
lock information, subject to availability in hardware.
Signed-off-by: Stephane Eranian eran...@google.com
---
include/linux/perf_event.h |2
fully operational, but there is a slight
improvement.
Enjoy,
Signed-off-by: Stephane Eranian eran...@google.com
Andi Kleen (2):
perf, core: Add a concept of a weightened sample
perf, tools: Add arbitary aliases and support names with -
Stephane Eranian (14):
perf/x86: improve sysfs event
the
put_event_constraint() call.
This mechanism is going to be used by the PEBS-LL patches.
It avoids defining yet another table to hold event specific
information.
Signed-off-by: Stephane Eranian eran...@google.com
---
arch/x86/kernel/cpu/perf_event.c |2 +-
arch/x86/kernel/cpu/perf_event.h
From: Andi Kleen a...@linux.intel.com
- Add missing scanner symbol for arbitrary aliases inside the config
region.
- looks nicer than _, so allow - in the event names. Used for various
of the arch perfmon and Haswell events.
Signed-off-by: Andi Kleen a...@linux.intel.com
---
From: Andi Kleen a...@linux.intel.com
For some events it's useful to weight sample with a hardware
provided number. This expresses how expensive the action the
sample represent was. This allows the profiler to scale
the samples to be more informative to the programmer.
There is already the
This patch extends Jiri's changes to make generic
events mapping visible via sysfs. The patch extends
the mechanism to non-generic events by allowing
the mappings to be hardcoded in strings.
This mechanism will be used by the PEBS-LL patch
later on.
Signed-off-by: Stephane Eranian eran
On Tue, Nov 6, 2012 at 2:31 PM, Andi Kleen a...@linux.intel.com wrote:
+EVENT_ATTR(cpu-cycles, CPU_CYCLES );
+EVENT_ATTR(instructions, INSTRUCTIONS);
+EVENT_ATTR(cache-references, CACHE_REFERENCES);
On Tue, Nov 6, 2012 at 4:44 PM, Arnaldo Carvalho de Melo
a...@redhat.com wrote:
Em Mon, Nov 05, 2012 at 02:51:01PM +0100, Stephane Eranian escreveu:
+
+ if (strcmp(mem_operation, MEM_OPERATION_LOAD))
+ sprintf(event, cpu/mem-stores/pp);
+ else
+ sprintf(event
On Tue, Nov 6, 2012 at 4:50 PM, Arnaldo Carvalho de Melo
a...@ghostprotocols.net wrote:
Em Tue, Nov 06, 2012 at 12:44:46PM -0300, Arnaldo Carvalho de Melo escreveu:
[root@sandy ~]# perf record -g -a -e cpu/mem-stores/
^C[ perf record: Woken up 25 times to write data ]
[ perf record: Captured
On Tue, Nov 6, 2012 at 7:50 PM, Andi Kleen a...@linux.intel.com wrote:
On Tue, Nov 06, 2012 at 03:29:01PM +0100, Stephane Eranian wrote:
On Tue, Nov 6, 2012 at 2:31 PM, Andi Kleen a...@linux.intel.com wrote:
+EVENT_ATTR(cpu-cycles, CPU_CYCLES );
+EVENT_ATTR
On Wed, Nov 7, 2012 at 8:38 AM, Namhyung Kim namhy...@kernel.org wrote:
Hi Arnaldo,
On Tue, 6 Nov 2012 17:52:21 -0300, Arnaldo Carvalho de Melo wrote:
Em Mon, Nov 05, 2012 at 02:50:47PM +0100, Stephane Eranian escreveu:
[root@sandy acme]# perf mem -t load rep --stdio
--sort=symbol
On Tue, Nov 6, 2012 at 8:37 PM, Stephane Eranian eran...@google.com wrote:
On Tue, Nov 6, 2012 at 7:50 PM, Andi Kleen a...@linux.intel.com wrote:
On Tue, Nov 06, 2012 at 03:29:01PM +0100, Stephane Eranian wrote:
On Tue, Nov 6, 2012 at 2:31 PM, Andi Kleen a...@linux.intel.com wrote
a...@linux.intel.com
Acked-by: Stephane Eranian eran...@google.com
---
arch/x86/kernel/cpu/perf_event.c | 29 +
arch/x86/kernel/cpu/perf_event.h |1 +
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c
b/arch/x86
On Wed, Nov 7, 2012 at 3:53 PM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2012/11/07 5:52), Arnaldo Carvalho de Melo wrote:
Em Mon, Nov 05, 2012 at 02:50:47PM +0100, Stephane Eranian escreveu:
Or if one is interested in the data view:
$ perf mem -t load rep --sort=symbol_daddr
Jiri,
When I run perf list, I see:
$ perf list
..
rNNN [Raw hardware
event descriptor]
cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware
event descriptor]
(see 'perf list --help' on how to encode it)
But:
$ perf list --help
$
From: Stephane Eranian eran...@gmail.com
The following patch set enforces exclusive PMU access for
Intel SandyBridge INST_REITRED:PREC_DIST event when used
with PEBS as described in the SDM Vol 3b. Without this,
the sample distribution may not be correct.
The kernel now rejects PEBS
PMU access (like on Intel SandyBridge).
Signed-off-by: Stephane Eranian eran...@google.com
---
tools/perf/util/parse-events.c |7 +++
tools/perf/util/parse-events.l |2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util
for that event.
This patch forces the INST_RETIRED:PREC_DIST event to have
the attr-exclusive bit set in order to be used with PEBS
on SNB. On Intel Ivybridge, that restriction is gone.
Signed-off-by: Stephane Eranian eran...@google.com
---
arch/x86/kernel/cpu/perf_event.h |2 +-
arch/x86/kernel
On Fri, Oct 19, 2012 at 5:13 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2012-10-19 at 16:52 +0200, Stephane Eranian wrote:
-modifier_event [ukhpGH]{1,8}
+modifier_event [ukhpGHx]{1,8}
wouldn't the max modifier sting length grow by adding another possible
modifier?
That's what I
On Fri, Oct 19, 2012 at 5:23 PM, Jiri Olsa jo...@redhat.com wrote:
On Fri, Oct 19, 2012 at 05:17:57PM +0200, Stephane Eranian wrote:
On Fri, Oct 19, 2012 at 5:13 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2012-10-19 at 16:52 +0200, Stephane Eranian wrote:
-modifier_event [ukhpGH
On Fri, Oct 19, 2012 at 5:49 PM, Andi Kleen a...@linux.intel.com wrote:
+ /*
+ * for INST_RETIRED.PREC_DIST to work correctly with PEBS, it must
+ * be measured alone on SNB (exclusive PMU access) as per Intel SDM.
+ */
+ if ((cfg INTEL_ARCH_EVENT_MASK) == 0x01c0
On Fri, Oct 19, 2012 at 5:53 PM, Jiri Olsa jo...@redhat.com wrote:
On Fri, Oct 19, 2012 at 05:47:11PM +0200, Stephane Eranian wrote:
On Fri, Oct 19, 2012 at 5:23 PM, Jiri Olsa jo...@redhat.com wrote:
On Fri, Oct 19, 2012 at 05:17:57PM +0200, Stephane Eranian wrote:
On Fri, Oct 19, 2012 at 5
On Fri, Oct 19, 2012 at 6:27 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2012-10-19 at 16:52 +0200, Stephane Eranian wrote:
+static int intel_pebs_aliases_snb(struct perf_event *event)
+{
+ u64 cfg = event-hw.config;
+ /*
+* for INST_RETIRED.PREC_DIST to work
On Sun, Oct 21, 2012 at 6:55 PM, Ingo Molnar mi...@kernel.org wrote:
* Andi Kleen a...@linux.intel.com wrote:
This isn't limited to admin, right? So the above turns into a DoS on
the
console.
Ok, so how about a WARN_ON_ONCE() instead?
That should be fine I guess ;-)
1 - 100 of 4055 matches
Mail list logo
