without
multiplexing.
Stephane Eranian (2):
perf/x86: update Haswell PEBS event constraints
perf/x86: fix constraint for load latency and precise store event
arch/x86/kernel/cpu/perf_event_intel.c|2 --
arch/x86/kernel/cpu/perf_event_intel_ds.c | 22 --
2 files
On Thu, Jun 5, 2014 at 10:29 AM, Peter Zijlstra wrote:
> On Wed, Jun 04, 2014 at 11:34:13PM +0200, Stephane Eranian wrote:
>> @@ -2020,12 +2050,29 @@ static void intel_pmu_cpu_starting(int cpu)
>>
>> if (x86_pmu.lbr_sel_map)
>> cpuc->lbr_
On Thu, Jun 5, 2014 at 11:33 PM, Andi Kleen wrote:
>> This hard assumes theres only ever 2 threads, which is true and I
>> suppose more in arch/x86 will come apart the moment Intel makes a chip
>> with more, still, do we have topology_thread_id() or so to cure this?
>
>
> Xeon Phi already has 4 th
On Thu, Jun 5, 2014 at 10:41 PM, Jiri Olsa wrote:
> On Thu, Jun 05, 2014 at 05:21:02PM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Thu, Jun 05, 2014 at 07:00:11PM +0200, Jiri Olsa escreveu:
>> > On Thu, Jun 05, 2014 at 06:06:41PM +0200, Stephane Eranian wro
On Thu, Jun 5, 2014 at 6:39 PM, Maria Dimakopoulou
wrote:
> On Thu, Jun 5, 2014 at 6:17 PM, Borislav Petkov wrote:
>> On Thu, Jun 05, 2014 at 05:45:24PM +0300, Maria Dimakopoulou wrote:
>>> The issue is that the outcoming leaked counts are not compensated
>>> by the incoming leaked counts of the
Hi Jiri,
Somehow, I thought you had written a fix to avoid the problem below.
But when I try with tip.git, the problem is still there.
Could you push your fix ASAP.
Thanks.
$ perf record -o - noploop 2 | perf inject -b | perf report -i -
# To display the perf.data header info, please use
--hea
On Thu, Jun 5, 2014 at 4:21 PM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 04:15:17PM +0200, Stephane Eranian wrote:
>> On Thu, Jun 5, 2014 at 4:04 PM, Peter Zijlstra wrote:
>> > On Wed, Jun 04, 2014 at 11:34:14PM +0200, Stephane Eranian wrote:
>> >> +
>&g
On Thu, Jun 5, 2014 at 4:21 PM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 04:15:17PM +0200, Stephane Eranian wrote:
>> On Thu, Jun 5, 2014 at 4:04 PM, Peter Zijlstra wrote:
>> > On Wed, Jun 04, 2014 at 11:34:14PM +0200, Stephane Eranian wrote:
>> >> +
>&g
On Thu, Jun 5, 2014 at 4:04 PM, Peter Zijlstra wrote:
> On Wed, Jun 04, 2014 at 11:34:14PM +0200, Stephane Eranian wrote:
>> +
>> + /*
>> + * Modify static constraint with current dynamic
>> + * state of thread
>> + *
>> + * EXCLUSI
On Thu, Jun 5, 2014 at 3:27 PM, Borislav Petkov wrote:
> On Thu, Jun 05, 2014 at 02:02:51PM +0200, Stephane Eranian wrote:
>> It is enabled by default. Nothing is done to try and disable it later
>> even once the kernel is fully booted. So this is mostly for testing
>> and
On Thu, Jun 5, 2014 at 3:19 PM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 11:29:33AM +0200, Stephane Eranian wrote:
>
>> If you know what you are doing (poweruser), then there are measurements
>> which works fine with the HT erratum. This is why we have the option.
>
On Thu, Jun 5, 2014 at 2:59 PM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 02:55:05PM +0200, Stephane Eranian wrote:
>> On Thu, Jun 5, 2014 at 2:50 PM, Peter Zijlstra wrote:
>> > On Thu, Jun 05, 2014 at 12:16:01PM +0100, Matt Fleming wrote:
>> >> On 5 Jun
On Thu, Jun 5, 2014 at 2:50 PM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 12:16:01PM +0100, Matt Fleming wrote:
>> On 5 June 2014 11:19, Stephane Eranian wrote:
>> > How would you know that you have a uniform workload from inside
>> > the kernel?
>&
On Thu, Jun 5, 2014 at 12:28 AM, Andi Kleen wrote:
>> There is no HW or FW workaround for this problem.
>
> Actually there is for global measurements:
>
> measure with Any bit set and divide by two.
>
> Please add a check that the any bit is set, and disable
> the workaround for that case.
>
I thi
On Thu, Jun 5, 2014 at 1:16 PM, Matt Fleming wrote:
> On 5 June 2014 11:19, Stephane Eranian wrote:
>> How would you know that you have a uniform workload from inside
>> the kernel?
>
> That's what I'm asking you ;-)
>
No way to know this otherwise we
On Thu, Jun 5, 2014 at 9:47 AM, Peter Zijlstra wrote:
> On Wed, Jun 04, 2014 at 11:34:13PM +0200, Stephane Eranian wrote:
>> From: Maria Dimakopoulou
>>
>> This patch adds a new shared_regs style structure to the
>> per-cpu x86 state (cpuc). It is used to coordinate
On Thu, Jun 5, 2014 at 12:01 PM, Matt Fleming wrote:
> On 5 June 2014 10:29, Stephane Eranian wrote:
>>
>> If you know what you are doing (poweruser), then there are measurements
>> which works fine with the HT erratum. This is why we have the option.
>>
>>
On Thu, Jun 5, 2014 at 10:32 AM, Matt Fleming wrote:
> On 4 June 2014 22:34, Stephane Eranian wrote:
>> From: Maria Dimakopoulou
>>
>> This patch adds a sysfs entry:
>>
>> /sys/devices/cpu/ht_bug_workaround
>>
>> to activate/deactivate
on demand.
Reviewed-by: Stephane Eranian
Signed-off-by: Maria Dimakopoulou
---
arch/x86/kernel/cpu/perf_event.h | 40 ++--
arch/x86/kernel/cpu/perf_event_intel.c | 63 +---
2 files changed, 94 insertions(+), 9 deletions(-)
diff --git a/arch
perf/x86: add syfs entry to disable HT bug workaround
Stephane Eranian (3):
perf,x86: rename er_flags to flags
pref/x86: vectorize cpuc->kfree_on_online
perf/x86: fix intel_get_event_constraints() for dynamic constraints
arch/x86/kernel/cpu/perf_event.c | 81 -
arch/x86/kerne
From: Maria Dimakopoulou
This patches activates the HT bug workaround for the
SNB/IVB/HSW processors. This covers non-PEBS mode.
Activation is done thru the constraint tables.
Both client and server processors needs this workaround.
Reviewed-by: Stephane Eranian
Signed-off-by: Maria
With dynamic constraint, we need to restart from the static
constraints each time the intel_get_event_constraints() is called.
Reviewed-by: Maria Dimakopoulou
Signed-off-by: Stephane Eranian
---
arch/x86/kernel/cpu/perf_event_intel.c | 15 ++-
1 file changed, 10 insertions(+), 5
es/cpu/ht_bug_workaround
Results effective only once there is no more active
events.
Reviewed-by: Stephane Eranian
Signed-off-by: Maria Dimakopoulou
---
arch/x86/kernel/cpu/perf_event.c | 31 +++
arch/x86/kernel/cpu/perf_event.h |5 +
arch/x86/kern
From: Maria Dimakopoulou
This patch modifies the PEBS constraint tables for SNB/IVB/HSW
such that corrupting events supporting PEBS activate the HT
workaround.
Reviewed-by: Stephane Eranian
Signed-off-by: Maria Dimakopoulou
---
arch/x86/kernel/cpu/perf_event_intel_ds.c | 40
each committed event
To be used optionally by model-specific code.
Reviewed-by: Stephane Eranian
Signed-off-by: Maria Dimakopoulou
---
arch/x86/kernel/cpu/perf_event.c |9 +
arch/x86/kernel/cpu/perf_event.h |8
2 files changed, 17 insertions(+)
diff --git a/arch/x86
Because it will be used for more than just
tracking the presence of extra registers.
Reviewed-by: Maria Dimakopoulou
Signed-off-by: Stephane Eranian
---
arch/x86/kernel/cpu/perf_event.h |9 ++---
arch/x86/kernel/cpu/perf_event_intel.c | 20 ++--
2 files changed
Make the cpuc->kfree_on_online a vector to accomodate
more than one entry and add the second entry to be
used by a later patch.
Reviewed-by: Maria Dimakopoulou
Signed-off-by: Stephane Eranian
---
arch/x86/kernel/cpu/perf_event.c | 10 +++---
arch/x86/kernel/cpu/perf_even
ruption. However, the workaround is still enabled,
yet not costing too much. Adding a dynamic detection of HT on turned out to
be complex are requiring too much to code to be justified.
This patch addresses the issue when PEBS is not used. A subsequent patch
fixes the problem when PEBS is used
On Mon, Jun 2, 2014 at 6:04 PM, Anshuman Khandual
wrote:
> On 06/02/2014 06:29 PM, Stephane Eranian wrote:
>> On Wed, May 28, 2014 at 10:04 AM, Anshuman Khandual
>> wrote:
>>> On 05/27/2014 05:39 PM, Stephane Eranian wrote:
>>>> I have been looking at those pa
On Wed, May 28, 2014 at 10:04 AM, Anshuman Khandual
wrote:
> On 05/27/2014 05:39 PM, Stephane Eranian wrote:
>> I have been looking at those patches and ran some tests.
>> And I found a few issues so far.
>>
>> I am running:
>> $ perf record -j any_ret -e cycles:u
On Wed, May 28, 2014 at 9:55 PM, Andi Kleen wrote:
>
>> Another explanation is that because we ACK the NMI early, we leave the
>> door open to other interrupts, incl. NIC, and we are interrupting the
>> execution
>
> PMI executes with interrupts off.
>
And that's coming from where?
>> of the PMU
Hi,
Some days ago, I was alerted that under important network load, something
is going wrong with perf_event sampling in frequency mode (such as perf top).
The number of samples was way too low given the cycle count (via perf stat).
Looking at the syslog, I noticed that the perf irq latency thrott
On Wed, May 28, 2014 at 7:25 PM, Andi Kleen wrote:
> On Wed, May 28, 2014 at 07:05:31PM +0200, Peter Zijlstra wrote:
>> On Wed, May 28, 2014 at 09:08:47AM -0700, Andi Kleen wrote:
>> > On Wed, May 28, 2014 at 05:35:48PM +0200, Peter Zijlstra wrote:
>> > > On Wed, May 28, 2014 at 07:58:31AM -0700,
On Wed, May 28, 2014 at 6:51 PM, Andi Kleen wrote:
>> The only part I don't quite follow here is this:
>> if (__test_and_set_bit(bit, (unsigned long *)&status))
>> continue;
>>
>> Which seems to indicate the code is making sure each counter is
On Wed, May 28, 2014 at 4:58 PM, Andi Kleen wrote:
>> In particular, the 0x90 offset (IA32_PERF_GLOBAL_STATUS). Intel once
>> confirmed to me that that is a direct copy of the similarly named MSR at
>> the time of the PEBS assist.
>
> That is correct.
>
>>
>> This is a problem, since if multiple c
On Wed, May 28, 2014 at 10:10 AM, Peter Zijlstra wrote:
> On Wed, May 28, 2014 at 02:18:09PM +0800, Yan, Zheng wrote:
>> PEBS always had the capability to log samples to its buffers without
>> an interrupt. Traditionally perf has not used this but always set the
>> PEBS threshold to one.
>>
>> For
the mux timer function
>
> s/\/timer/ -- because that's the normal way of calling things.
>
> Fixes: 62b856397927 ("perf: Add sysfs entry to adjust multiplexing interval
> per PMU")
> Cc: Stephane Eranian
> Reported-by: Thomas Gleixner
> Signed-off-by:
Hi,
On Mon, May 5, 2014 at 11:09 AM, Anshuman Khandual
wrote:
>
> This patchset is the re-spin of the original branch stack
> sampling
> patchset which introduced new PERF_SAMPLE_BRANCH_COND branch filter. This
> patchset
> also enables SW based branch filtering support for boo
From: Michael Lentine
This patch adds a fallback to cat for the pager. This is useful
on environmnents, such as Android, where less does not exist.
It is better to default to cat than to abort.
Reviewed-by: Stephane Eranian
Signed-off-by: Michael Lentine
---
tools/perf/util/pager.c | 12
From: Michael Lentine
This short series of patches allow for the execution of perf natively
on the android devices.
The following changes are implemented:
- Have cat be the default page. Android does not have less or more pager.
this is a generic change which cleans up the code a bit
- Re
NDK.
Reviewed-by: Stephane Eranian
Signed-off-by: Michael Lentine
---
tools/perf/util/map.c | 95 ++-
1 file changed, 94 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index ba5f5c0c..e1974e7 100644
--- a
e mux timer function
>
> s/\/timer/ -- because that's the normal way of calling things.
>
Ok, thanks for fixing all of this.
> Fixes: 62b856397927 ("perf: Add sysfs entry to adjust multiplexing interval
> per PMU")
> Cc: Stephane Eranian
> Reported-by: Thomas
Commit-ID: 722e76e60f2775c21b087ff12c5e678cf0ebcaaf
Gitweb: http://git.kernel.org/tip/722e76e60f2775c21b087ff12c5e678cf0ebcaaf
Author: Stephane Eranian
AuthorDate: Thu, 15 May 2014 17:56:44 +0200
Committer: Thomas Gleixner
CommitDate: Mon, 19 May 2014 21:52:59 +0900
fix Haswell
From: Michael Lentine
This short series of patches allow for the execution of perf natively
on the android devices.
The following changes are implemented:
- Have cat be the default page. Android does not have less or more pager.
this is a generic change which cleans up the code a bit
- Re
From: Michael Lentine
This patch automtically adjusts the path of MMAP records
associated with Android system libraries. It enables running
perf reporting tools directly on the Android system natively.
Reviewed-by: Stephane Eranian
Signed-off-by: Michael Lentine
---
tools/perf/util/map.c
From: Michael Lentine
This patch adds a fallback to cat for the pager. This is useful
on environmnents, such as Android, where less does not exist.
It is better to default to cat than to abort.
Reviewed-by: Stephane Eranian
Signed-off-by: Michael Lentine
---
tools/perf/util/pager.c | 12
From: Michael Lentine
This patch automtically adjusts the path of MMAP records
associated with Android system libraries. It enables running
perf reporting tools directly on the Android system natively.
Reviewed-by: Stephane Eranian
Signed-off-by: Michael Lentine
---
tools/perf/util/map.c
From: Michael Lentine
This short series of patches allow for the execution of perf natively
on the android devices.
The following changes are implemented:
- Have cat be the default page. Android does not have less or more pager.
this is a generic change which cleans up the code a bit
- Re
From: Michael Lentine
This patch adds a fallback to cat for the pager. This is useful
on environmnents, such as Android, where less does not exist.
It is better to default to cat than to abort.
Reviewed-by: Stephane Eranian
Signed-off-by: Michael Lentine
---
tools/perf/util/pager.c | 12
On Fri, May 16, 2014 at 6:24 PM, Don Zickus wrote:
> On Fri, May 16, 2014 at 06:02:43PM +0200, Stephane Eranian wrote:
>> On Fri, May 16, 2014 at 5:59 PM, Peter Zijlstra wrote:
>> > On Fri, May 16, 2014 at 04:09:59PM +0200, Stephane Eranian wrote:
>> >> > +#defin
On Fri, May 16, 2014 at 5:59 PM, Peter Zijlstra wrote:
> On Fri, May 16, 2014 at 04:09:59PM +0200, Stephane Eranian wrote:
>> > +#define CACHE_LINESIZE 64
>> I had something similar to your patch here in my original series for
>> perf mem, but I never pushed it.
>
On Tue, May 13, 2014 at 6:48 PM, Don Zickus wrote:
> In perf's 'mem-mode', one can get access to a whole bunch of details specific
> to a
> particular sample instruction. A bunch of those details relate to the data
> address.
>
> One interesting thing you can do with data addresses is to convert
On Thu, May 15, 2014 at 9:56 PM, Don Zickus wrote:
> On Thu, May 15, 2014 at 05:56:44PM +0200, Stephane Eranian wrote:
>>
>> This patch fixes a bug in precise_store_data_hsw() whereby
>> it would set the data source memory level to the wrong value.
>>
>> As p
Signed-off-by: Stephane Eranian
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index ae96cfa..980970c 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -108,15 +108,31 @@ static u64
On Thu, May 15, 2014 at 4:32 PM, Andi Kleen wrote:
> On Thu, May 15, 2014 at 01:53:37PM +0200, Stephane Eranian wrote:
>>
>> This patches fixes a bug in precise_store_data_hsw() whereby
>> it would set the data source memory level to the wrong value.
>>
>> As p
.
This patch encodes the memory level according to the specification.
Signed-off-by: Stephane Eranian
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index ae96cfa..81424f6 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86
On Wed, May 14, 2014 at 10:50 PM, Don Zickus wrote:
>
> Hi Andi,
>
> Joe was playing with our c2c tool today and noticed we were losing store
> events from perf's mem-stores event. Upon investigation we stumbled into
> some differences in data that Haswell reports vs. Ivy/Sandy Bridge.
>
> This l
On Wed, May 7, 2014 at 5:04 PM, Peter Zijlstra wrote:
> On Wed, Apr 30, 2014 at 09:24:08AM +0900, Namhyung Kim wrote:
>> Hi Jiri and Peter,
>>
>> On Tue, 29 Apr 2014 13:37:47 +0200, Jiri Olsa wrote:
>> > On Tue, Apr 29, 2014 at 01:19:39PM +0200, Peter Zijlstra wrote:
>> >> On Tue, Apr 29, 2014 at
ow can do it in any thread.
>
Your patch makes the code more meaningful for sure.
The pid, pid looked like a bug to me at first, but then I realized,
that yes, it is
look for the main thread.
Acked-by: Stephane Eranian
>
> It fixes a bug when each thread has different name, it only rep
On Thu, Apr 24, 2014 at 3:27 PM, Namhyung Kim wrote:
> The on_exit() function was only used in perf record but it's gone in
> previous patch.
>
Acked-by: Stephane Eranian
> Cc: Bernhard Rosenkraenzer
> Cc: Irina Tirdea
> Signed-off-by: Namhyung Kim
> ---
>
gt;
> And Jiri's case (error in parent):
>
> $ perf record -m 10G true && echo yes || echo no
> rounding mmap pages size to 17179869184 bytes (4194304 pages)
> failed to mmap with 12 (Cannot allocate memory)
> no
>
Works for
On Thu, Apr 24, 2014 at 12:25 PM, Yan, Zheng wrote:
> On 04/24/2014 04:14 PM, Ingo Molnar wrote:
>>
>> * Stephane Eranian wrote:
>>
>>>>> Most of the codes without comments are hardware specific codes.
>>>>> The corresponding contents in Intel u
On Thu, Apr 24, 2014 at 9:20 AM, Ingo Molnar wrote:
>
> * Stephane Eranian wrote:
>
>> On Tue, Apr 22, 2014 at 12:17 AM, Bjorn Helgaas wrote:
>> > Work around BIOSes that don't report the entire Intel MCH area.
>> >
>> > MCHBAR is not an architect
Commit-ID: 9f7ff8931e3c5ddc8535476971ec9501e9555c05
Gitweb: http://git.kernel.org/tip/9f7ff8931e3c5ddc8535476971ec9501e9555c05
Author: Stephane Eranian
AuthorDate: Wed, 23 Apr 2014 19:04:19 +0200
Committer: Ingo Molnar
CommitDate: Thu, 24 Apr 2014 08:12:41 +0200
perf/x86: Fix RAPL
This patch fixes a bug introduced by commit 24223657.
The rdmsrl_safe() function returns 0 on success.
The current code was failing to detect the RAPL PMU
on real hardware (missing /sys/devices/power) because
the return value of rdmsrl_safe() was misinterpreted.
Signed-off-by: Stephane Eranian
On Wed, Apr 23, 2014 at 5:35 PM, Borislav Petkov wrote:
> On Wed, Apr 23, 2014 at 05:18:29PM +0200, Stephane Eranian wrote:
>> On Wed, Apr 23, 2014 at 5:16 PM, Borislav Petkov wrote:
>> > On Wed, Apr 23, 2014 at 05:14:33PM +0200, Stephane Eranian wrote:
>> >> Woul
On Wed, Apr 23, 2014 at 5:16 PM, Borislav Petkov wrote:
> On Wed, Apr 23, 2014 at 05:14:33PM +0200, Stephane Eranian wrote:
>> Wouldn't rdmsrl_safe() return 0 on success?
>
> Yes.
>
then the if() test is wrong:
if (!rdmsrl_safe())
return -1;
Should be:
if (rdmsrl_safe()
On Wed, Apr 23, 2014 at 5:09 PM, Peter Zijlstra wrote:
> On Wed, Apr 23, 2014 at 04:49:55PM +0200, Stephane Eranian wrote:
>> On your machine, booted with 3.15-rc2, do you have /sys/devices/power?
>> If not, and you have at least an SNB, you should have RAPL and that
>> RAPL_
Don,
On Wed, Apr 23, 2014 at 3:30 PM, Don Zickus wrote:
> On Wed, Apr 23, 2014 at 02:52:09PM +0200, Stephane Eranian wrote:
>> On Tue, Apr 22, 2014 at 10:45 PM, Don Zickus wrote:
>> > On Tue, Apr 22, 2014 at 09:50:17PM +0200, Stephane Eranian wrote:
>> >> On Tue
On Wed, Apr 23, 2014 at 4:45 PM, Peter Zijlstra wrote:
> On Wed, Apr 23, 2014 at 04:31:32PM +0200, Stephane Eranian wrote:
>> On Thu, Mar 13, 2014 at 8:36 PM, Venkatesh Srinivas
>> wrote:
>> > CPUs which should support the RAPL counters according to
>> > Family/M
file for my own taste. Hard
to navigate and I spend quite some time looking at it and modifying it!
You could follow the model of the core PMU support files.
You'd have a "core" file with the common routines, and then
a file perf processor:
- perf_event_intel_uncore.c
- per
On Wed, Apr 23, 2014 at 4:38 PM, Namhyung Kim wrote:
> Hi Stephane,
>
> 2014-04-23 (수), 14:11 +0200, Stephane Eranian:
>> On Wed, Apr 23, 2014 at 8:40 AM, Namhyung Kim wrote:
>> > +out_child:
>> > + if (forks) {
>> > + i
On Thu, Mar 13, 2014 at 8:36 PM, Venkatesh Srinivas
wrote:
> CPUs which should support the RAPL counters according to
> Family/Model/Stepping may still issue #GP when attempting to access
> the RAPL MSRs. This may happen when Linux is running under KVM and
> we are passing-through host F/M/S data,
find a PNP0C02 resource that covers part of the MCH
> space, extend it to cover the entire space.
>
Works for me on my Levono IvyBridge laptop.
Thanks for fixing this, Bjorn.
Acked-by: Stephane Eranian
> Link: http://lkml.kernel.org/r/20140224162400.ge16...@pd.tnic
> Reported-by: Borisl
On Tue, Apr 22, 2014 at 10:45 PM, Don Zickus wrote:
> On Tue, Apr 22, 2014 at 09:50:17PM +0200, Stephane Eranian wrote:
>> On Tue, Apr 22, 2014 at 9:40 PM, Don Zickus wrote:
>> > On Mon, Apr 21, 2014 at 06:06:55PM +0200, Stephane Eranian wrote:
>> >> perf tools:
data ]
> [ perf record: Captured and wrote 0.013 MB perf.data (~589 samples) ]
> no
>
> And Jiri's case (error in parent):
>
> $ perf record -m 10G true && echo yes || echo no
> rounding mmap pages size to 17179869184 bytes (4194304 pages)
> failed to m
On Tue, Apr 22, 2014 at 10:54 PM, Andi Kleen wrote:
>> Does anyone have any thoughts or experience on this?
>
> perf has a JIT interface today, but it's extremely primitive
> and only supports symbols. Clearly it could be done better.
>
> Various JITs (e.g. Java) have special debug interfaces for
On Tue, Apr 22, 2014 at 9:40 PM, Don Zickus wrote:
> On Mon, Apr 21, 2014 at 06:06:55PM +0200, Stephane Eranian wrote:
>> perf tools: fix processing of pid/tid for mmap records
>>
>> Mmaps are global to a process (always). Processing them
>> per-thread was causing
Hi Don,
I have been working on the JIT code support for a while now.
I have something working well for more than Java now. It reuses
some of the same principles as the OProfile support but extend
them to support more advanced JIT features such as address
recycling and code movements.
I intend to
Jiri,
On Tue, Apr 22, 2014 at 3:32 PM, Jiri Olsa wrote:
> hi,
>
> On Mon, Apr 21, 2014 at 06:06:55PM +0200, Stephane Eranian wrote:
>> perf tools: fix processing of pid/tid for mmap records
>
> extra description line ^^^
>
>>
>> Mmaps are global to a proc
*sample)
{
struct thread *thread = machine__findnew_thread(machine, sample->pid,
sample->pid);
}
Without this fix, some samples in overlapping regions
may not be symbolized.
Signed-off-by: Stephane Eranian
diff --git a/tool
On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas wrote:
> On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
>> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
>> > Right. Even if we had this long-term solution, we'd still have
>> > Stephane's current problem, because t
On Tue, Apr 15, 2014 at 1:35 PM, Kirill A. Shutemov
wrote:
> On Wed, Mar 12, 2014 at 12:53:30AM +0100, Stephane Eranian wrote:
>>
>> This patch fixes a compilation problem (unused variable) with the
>> new SNB/IVB/HSW uncore IMC code.
>>
>> In V2, we simpl
Hi,
On Thu, Apr 10, 2014 at 2:30 AM, Jet Chen wrote:
> Hi Stephane,
>
> I got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit 71ad88efebbcde374bddf904b96f3a7fc82d45d4
> Author: Stephane
Hi,
There is a discrepancy in the way perf stat and perf record propagate
command error code back when they launch a process:
$ perf record -e cycles false && echo "yes" || echo "no"
yes
That's wrong!
But perf stat:
$ perf stat -e cycles false && echo "yes" || echo "no"
no
That's correct!
Yo
On Wed, Mar 26, 2014 at 9:31 PM, Andrew Morton
wrote:
> On Tue, 25 Mar 2014 01:59:10 +0300 Artem Fetishev
> wrote:
>
>> On x86 uniprocessor systems topology_physical_package_id() returns -1 which
>> causes rapl_cpu_prepare() to leave rapl_pmu variable uninitialized which
>> leads
>> to GPF in r
On Tue, Mar 25, 2014 at 10:01 PM, Andi Kleen wrote:
>>
>> Timestamp are useful to order samples during reporting.
>> How do you do with it if you monitor multi-threaded (multi-cpu)
>> workloads. This is only good for single thread or single CPU
>> measurements. Or am I missing something?
>
> For a
On Tue, Mar 25, 2014 at 9:44 PM, Andi Kleen wrote:
>
> From: Andi Kleen
>
> [post with updated description]
>
> Time stamps are always implicitely enabled for record currently.
> The old --time/-T option is a nop.
>
> The time stamps are needed to handle library mmaps correctly.
> This mainly mat
On Thu, Mar 20, 2014 at 9:16 AM, Yan, Zheng wrote:
> On 03/20/2014 03:53 PM, Zhang, Rui wrote:
>> The resource length is also hardcoded to 0x6000, right?
>> This is probably a problem, because
>> only if the resource length read from PCI config space is larger than 0x4000,
>> drivers/pnp/quirks.c
g
>> List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian
>> Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
>> Importance: High
>>
>> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
>> > [CC list rearranged]
>> >
>
On Thu, Mar 20, 2014 at 3:24 AM, Aaron Lu wrote:
> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
>> [CC list rearranged]
>>
>> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
>>> This started happening this morning after booting -rc4+tip, let's
>>> add *everybody* to CC :-)
>>>
Rafael,
Thanks for the analysis.
On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov wrote:
> On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
>> I've just gone throught this.
>
> Thanks.
>
>> So the problem is that we have the PNP "system" driver whose only purpose
>> seems
>>
Commit-ID: 81827ed8d85e892311965dc9ec4120b2b2e745bd
Gitweb: http://git.kernel.org/tip/81827ed8d85e892311965dc9ec4120b2b2e745bd
Author: Stephane Eranian
AuthorDate: Thu, 13 Mar 2014 13:04:36 +0100
Committer: Ingo Molnar
CommitDate: Fri, 14 Mar 2014 09:25:25 +0100
perf/x86/uncore: Fix
On Thu, Mar 13, 2014 at 6:17 PM, Andi Kleen wrote:
> Stephane Eranian writes:
>
>> This patch fixes a bug with the SNB/IVB/HSW uncore
>> mmeory controller support.
>>
>> The PCI Ids tables for the memory controller were missing end markers.
>> That could ca
This patch fixes a bug with the SNB/IVB/HSW uncore
mmeory controller support.
The PCI Ids tables for the memory controller were missing end markers.
That could cause random crashes on boot during or after PCI device
registration.
Signed-off-by: Stephane Erainan
--
diff --git a/arch/x86/kernel/c
On Tue, Mar 11, 2014 at 4:33 AM, Arnaldo Carvalho de Melo
wrote:
> Em Mon, Mar 10, 2014 at 10:57:48PM +0100, Stephane Eranian escreveu:
>> Arnaldo,
>>
>> I am using tip.git perf and I do the following:
>>
>> $ perf record -e cycles,instructions foo
>> $ p
Commit-ID: 4191c29f0593e82d19c3cd05de67e55467aca6b5
Gitweb: http://git.kernel.org/tip/4191c29f0593e82d19c3cd05de67e55467aca6b5
Author: Stephane Eranian
AuthorDate: Wed, 12 Mar 2014 00:53:30 +0100
Committer: Ingo Molnar
CommitDate: Wed, 12 Mar 2014 10:49:13 +0100
perf/x86/uncore: Fix
On Wed, Mar 12, 2014 at 8:05 AM, Peter Zijlstra wrote:
> On Wed, Mar 12, 2014 at 12:53:30AM +0100, Stephane Eranian wrote:
>> #ifdef CONFIG_PHYS_ADDR_T_64BIT
>> - pci_read_config_dword(pdev, SNB_UNCORE_PCI_IMC_BAR_OFFSET+4, &addr_hi);
>> - addr = ((reso
This patch fixes a compilation problem (unused variable) with the
new SNB/IVB/HSW uncore IMC code.
In V2, we simplify the fix as suggested by Peter Zjilstra.
Reported-by: Stephen Rothwell
Signed-off-by: Stephane Eranian
--
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch
On Tue, Mar 11, 2014 at 12:13 PM, Peter Zijlstra wrote:
> On Tue, Mar 11, 2014 at 11:44:33AM +0100, Stephane Eranian wrote:
>>
>>
>> This patches fixes a compilation problem (unused variable) with the
>> new SNB/IVB/HSW uncore IMC code.
>>
>> Reported
901 - 1000 of 2097 matches
Mail list logo
