On Sat, Feb 3, 2018 at 7:30 AM, Jiri Olsa wrote:
> On Fri, Feb 02, 2018 at 10:45:46AM -0800, Stephane Eranian wrote:
>> Jiri,
>>
>> On Thu, Feb 1, 2018 at 12:38 AM, Jiri Olsa wrote:
>> > Stephane reported that we don't set properly PERIOD
>> > sam
On Fri, Feb 2, 2018 at 12:40 PM, Arnaldo Carvalho de Melo
wrote:
> Em Fri, Feb 02, 2018 at 05:28:49PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Feb 02, 2018 at 10:45:46AM -0800, Stephane Eranian escreveu:
>> > Otherwise, I tested what you have written so far and i
ixed as well.
I'd like to be able to say:
$ perf record -e
cycles:pp:period=1001,cpu/event=0xd0,umaks=0x81,period=10/
Or something equivalent.
Otherwise, I tested what you have written so far and it works.
Thanks.
> Reported-by: Stephane Eranian
> Link: http://lkml.kernel.o
On Tue, Jan 30, 2018 at 10:52 AM, Jiri Olsa wrote:
>
> On Tue, Jan 30, 2018 at 11:48:18AM -0500, Liang, Kan wrote:
>
> SNIP
>
> > > >
> > > > The events in fixed mode could enable large PEBS. Events in freq mode
> > > > should
> > > > not enable large PEBS.
> > > > I think that could be a problem
On Tue, Jan 30, 2018 at 7:25 AM, Liang, Kan wrote:
>
>
> On 1/30/2018 10:04 AM, Jiri Olsa wrote:
>>
>> On Tue, Jan 30, 2018 at 09:59:15AM -0500, Liang, Kan wrote:
>>>
>>>
>>>
>>> On 1/30/2018 8:39 AM, Jiri Olsa wrote:
>>>>
Hi,
On Mon, Jan 29, 2018 at 8:29 AM, wrote:
>
> From: Kan Liang
>
> --
>
> Changes since V2:
> - Refined the changelog
> - Introduced specific read function for large PEBS.
>The previous generic PEBS read function is confusing.
>Disabled PMU in pmu::read() path for large PEBS.
>
On Fri, Jan 19, 2018 at 12:50 PM, Stephane Eranian wrote:
> On Fri, Jan 19, 2018 at 12:24 PM, Andi Kleen wrote:
>>> Oh, think a bit more.
>>> I think we cannot do the same thing as we did for CPU PMU's fixed counters.
>>>
>>> The counters here are free
On Fri, Jan 19, 2018 at 12:24 PM, Andi Kleen wrote:
>> Oh, think a bit more.
>> I think we cannot do the same thing as we did for CPU PMU's fixed counters.
>>
>> The counters here are free running counters. They cannot be start/stop.
>
> Yes free running counter have completely different semantics
On Fri, Jan 19, 2018 at 10:00 AM, Liang, Kan wrote:
>
> > On Fri, Jan 19, 2018 at 9:53 AM, Liang, Kan wrote:
> > >> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote:
> > >> > >
> > >> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote:
> > >> > > > In the uncore document, th
On Fri, Jan 19, 2018 at 9:53 AM, Liang, Kan wrote:
>> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote:
>> > >
>> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote:
>> > > > In the uncore document, there is no event-code assigned to free
>> > > > running
>> > > counters.
>>
On Fri, Jan 19, 2018 at 9:19 AM, Peter Zijlstra wrote:
>
> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote:
> > >
> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote:
> > > > In the uncore document, there is no event-code assigned to free running
> > > counters.
> > > > Som
Commit-ID: 9ae21dd66b970b5e3192a636353d75ede0529338
Gitweb: https://git.kernel.org/tip/9ae21dd66b970b5e3192a636353d75ede0529338
Author: Stephane Eranian
AuthorDate: Fri, 5 Jan 2018 08:18:52 -0800
Committer: Ingo Molnar
CommitDate: Sat, 6 Jan 2018 12:17:39 +0100
perf/x86/msr: Add
-by: Stephane Eranian
---
arch/x86/events/msr.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c
index 14efaa0e8684..0be15b9b2376 100644
--- a/arch/x86/events/msr.c
+++ b/arch/x86/events/msr.c
@@ -10,7
will be generated in the output
.so files from the jitted code.
In v2, we removed the extraneaous echo in the make target.
In v3, we removed the superfluous -lelf from the static build DWARFLIBS.
Signed-off-by: Stephane Eranian
---
tools/build/feature/Makefile | 9 +++--
tools/perf/bu
Hi,
The following patch:
f785657b0fbe perf report: Fix regression when decoding Intel-PT traces
is breaking perf report for me. I get no samples reported from perf report
when running simple perf record commands:
$ perf record -e cycles noploop
Reverting the patch fixes the problem.
Are you
On Sun, Dec 17, 2017 at 7:05 PM, Jiri Olsa wrote:
> On Fri, Dec 08, 2017 at 09:02:18AM -0800, Stephane Eranian wrote:
>> I ran into problems trying to use the JIT support and display
>> source-level information. Basically, there was no dwarf debug
>> info generated in the ji
will be generated in the output
.so files from the jitted code.
In v2, we removed the extraneaous echo in the make target.
Signed-off-by: Stephane Eranian
---
tools/build/feature/Makefile | 7 ++-
tools/perf/builtin-inject.c | 3 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --
Hi,
On Wed, Nov 29, 2017 at 8:27 AM, Ben Gainey wrote:
> On Wed, 2017-11-29 at 05:02 -0800, Stephane Eranian wrote:
>> On Thu, Nov 23, 2017 at 7:22 AM, Arnaldo Carvalho de Melo
>> wrote:
>> >
>> > Em Wed, Nov 22, 2017 at 06:25:41PM -0600, Kim Phillips
ll be generated in the output
.so files from the jitted code.
Signed-off-by: Stephane Eranian
---
tools/build/feature/Makefile | 8 +++-
tools/perf/builtin-inject.c | 3 +++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Mak
On Thu, Nov 23, 2017 at 7:22 AM, Arnaldo Carvalho de Melo
wrote:
>
> Em Wed, Nov 22, 2017 at 06:25:41PM -0600, Kim Phillips escreveu:
> > From: Ben Gainey
> > @@ -405,7 +405,9 @@ jvmti_write_debug_info(void *agent, uint64_t code,
> > const char *file,
> > return -1;
> > }
> >
On Mon, Nov 20, 2017 at 2:50 PM, Milian Wolff wrote:
> On Montag, 20. November 2017 21:53:04 CET Stephane Eranian wrote:
>> Hi,
>>
>> I have been using the perf script -F option on the latest perf and I
>> find it not very convenient to use. I appreciate the + and -
Hi,
I have been using the perf script -F option on the latest perf and I
find it not very convenient to use. I appreciate the + and - prefix to
field names to add or suppress them. But most of the time, I want to
print only one or two fields and I have to guess which ones are there
by default so I
oth at the same time. This patch makes this possible by specifying
PERF_SAMPLE_IP|PERF_SAMPLE_SKID_IP.
Signed-off-by: Stephane Eranian
---
include/linux/perf_event.h | 2 ++
include/uapi/linux/perf_event.h | 4 +++-
kernel/events/core.c| 14 ++
3 files changed,
This patch adds the support code to handle the PERF_SAMPLE_SKID_IP
record type. This is done as an event term and as such can be enabled
per event: cpu/event=xxx,skid-ip=1/. This is a boolean term which is
false by default.
Signed-off-by: Stephane Eranian
---
tools/include/uapi/linux
branches and their target.
Signed-off-by: Stephane Eranian
---
tools/perf/Documentation/perf-record.txt | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 5a626ef666c2..f0e3636dc4be 100644
--- a/tools
This atch adds support for SKID_IP to Intel x86 processors in PEBS
mode.
Signed-off-by: Stephane Eranian
---
arch/x86/events/intel/ds.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 3674a4b6f8bd..dd248ceda452 100644
This patch adds a skid_ip field to perf script
to dump the raw value of the PERF_SAMPLE_SKID_IP
field in each sample.
$ perf script -F +ip,+skid_ip ..
The field is not enabled by default.
Signed-off-by: Stephane Eranian
---
tools/perf/Documentation/perf-script.txt | 2 +-
tools/perf
new way to specify skid ip is per event:
$ perf record -e cpu/event=0xc5,skid-ip=1/
In V4, we fix document of the ski-ip event option and move a session.c
change to the correct patch as per Jiri's remark.
Stephane Eranian (5):
perf/core: add PERF_RECORD_SAMPLE_SKID_IP record type
On Wed, Nov 8, 2017 at 12:56 PM, Andi Kleen wrote:
>> diff --git a/tools/perf/Documentation/perf-record.txt
>> b/tools/perf/Documentation/perf-record.txt
>> index 5a626ef666c2..3b156fa03c99 100644
>> --- a/tools/perf/Documentation/perf-record.txt
>> +++ b/tools/perf/Documentation/perf-record.txt
oth at the same time. This patch makes this possible by specifying
PERF_SAMPLE_IP|PERF_SAMPLE_SKID_IP.
Signed-off-by: Stephane Eranian
---
include/linux/perf_event.h | 2 ++
include/uapi/linux/perf_event.h | 4 +++-
kernel/events/core.c| 14 ++
3 files changed,
This patch adds support for SKID_IP for Intel x86 processors
when PEBS mode is enabled.
Signed-off-by: Stephane Eranian
---
arch/x86/events/intel/ds.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 3674a4b6f8bd
This patch adds the support code to handle the PERF_SAMPLE_SKID_IP
record type. This is done as an event term and as such can be enabled
per event: cpu/event=xxx,skid-ip=1/. This is a boolean term which is
false by default.
Signed-off-by: Stephane Eranian
---
tools/include/uapi/linux
branches and their target.
Signed-off-by: Stephane Eranian
---
tools/perf/Documentation/perf-record.txt | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 5a626ef666c2..3b156fa03c99 100644
--- a/tools
This patch adds a skid_ip field to perf script
to dump the raw value of the PERF_SAMPLE_SKID_IP
field in each sample.
$ perf script -F +ip,+skid_ip ..
The field is not enabled by default.
Signed-off-by: Stephane Eranian
---
tools/perf/Documentation/perf-script.txt | 2 +-
tools/perf
new way to specify skid ip is per event:
$ perf record -e cpu/event=0xc5,skid-ip=1/
Stephane Eranian (5):
perf/core: add PERF_RECORD_SAMPLE_SKID_IP record type
perf/x86: add PERF_SAMPLE_SKID_IP support for X86 PEBS
perf/tools: add support for PERF_SAMPLE_SKID_IP
perf/record: add
On Thu, Nov 2, 2017 at 11:59 AM, Peter Zijlstra wrote:
> On Thu, Nov 02, 2017 at 11:15:55AM -0700, Stephane Eranian wrote:
>
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index 874b71a70058..772530501025 100644
>> --- a/include/linux/perf_
From: Stephane Eranian
This atch adds support for SKID_IP to Intel x86 processors in PEBS
mode.
Signed-off-by: Stephane Eranian
---
arch/x86/events/intel/ds.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index e1965e5ff570
From: Stephane Eranian
This patchs adds a new sample record type. The goal
is to record the interrupted instruction pointer (IP)
as seen by the kernel and reflected in the machine state (pt_regs).
On some architectures, it is possible to avoid the IP skid using
hardware support. For instance
to collect both IPs in a single run to determine
how often the conditional branch is taken vs. non-taken.
Understanding the skid is also interesting for other precise events.
In V2, we rebased to 10d94ff4d558 (v4.14-rc7).
Stephane Eranian (5):
perf/core: add PERF_RECORD_SAMPLE_SKID_IP record
event and precise sampling mode.
$ perf record --skid-ip .
Signed-off-by: Stephane Eranian
---
tools/perf/Documentation/perf-record.txt | 8
tools/perf/builtin-record.c | 2 ++
2 files changed, 10 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b
From: Stephane Eranian
This patch adds a skid_ip field to perf script
to dump the raw value of the PERF_SAMPLE_SKID_IP
field in each sample.
$ perf script -F +ip,+skid_ip ..
Signed-off-by: Stephane Eranian
---
tools/perf/builtin-script.c | 6 ++
tools/perf/util/session.c | 2 +-
2
This patch adds the support code to handle the PERF_SAMPLE_SKID_IP
record type.
Signed-off-by: Stephane Eranian
---
tools/include/uapi/linux/perf_event.h | 4 +++-
tools/perf/perf.h | 1 +
tools/perf/util/event.h | 1 +
tools/perf/util/evsel.c
On Tue, Oct 17, 2017 at 12:54 PM, Liang, Kan wrote:
>> On Mon, Oct 16, 2017 at 3:26 PM, wrote:
>> > From: Kan Liang
>> >
>> > There could be different types of memory in the system. E.g normal
>> > System Memory, Persistent Memory. To understand how the workload
>> maps to
>> > those memories,
On Mon, Oct 16, 2017 at 3:26 PM, wrote:
> From: Kan Liang
>
> There could be different types of memory in the system. E.g normal
> System Memory, Persistent Memory. To understand how the workload maps to
> those memories, it's important to know the I/O statistics on different
> type of memorys.
On Thu, Aug 31, 2017 at 12:51 PM, Stephane Eranian wrote:
> Hi,
>
> On Thu, Aug 31, 2017 at 10:18 AM, Peter Zijlstra wrote:
>> On Wed, Aug 23, 2017 at 11:54:15AM +0300, Alexey Budankov wrote:
>>> On 22.08.2017 23:47, Peter Zijlstra wrote:
>>> > On Thu, Aug
On Fri, Sep 1, 2017 at 12:59 AM, Jiri Olsa wrote:
> On Wed, Aug 30, 2017 at 11:21:23PM -0700, Stephane Eranian wrote:
>> Hi,
>>
>>
>> On Mon, Aug 28, 2017 at 1:41 PM, Andi Kleen wrote:
>> >> So I think we are good to go. to capture multiplexing scaling fact
Hi,
On Thu, Aug 31, 2017 at 10:18 AM, Peter Zijlstra wrote:
> On Wed, Aug 23, 2017 at 11:54:15AM +0300, Alexey Budankov wrote:
>> On 22.08.2017 23:47, Peter Zijlstra wrote:
>> > On Thu, Aug 10, 2017 at 06:57:43PM +0300, Alexey Budankov wrote:
>> >> The key thing in the patch is explicit updating
Hi,
On Mon, Aug 28, 2017 at 1:41 PM, Andi Kleen wrote:
>> So I think we are good to go. to capture multiplexing scaling factor
>> when sampling simply use the S
>> modifier.
>> But to my surprise, newer kernels are not happy with the cmdline:
>> $ perf record -e cycles:S noploop 1
>> Error:
>>
Hi,
On Tue, Aug 22, 2017 at 12:24 AM, Stephane Eranian wrote:
> On Tue, Aug 22, 2017 at 12:03 AM, Jiri Olsa wrote:
>>
>> On Mon, Aug 21, 2017 at 06:25:45PM -0700, Andi Kleen wrote:
>> > On Mon, Aug 21, 2017 at 05:13:29PM -0700, Stephane Eranian wrote:
>> >
On Wed, Aug 23, 2017 at 7:39 AM, Peter Zijlstra wrote:
> On Wed, Aug 23, 2017 at 04:33:08PM +0200, Peter Zijlstra wrote:
>> > @@ -6145,6 +6183,9 @@ void perf_prepare_sample(struct perf_event_header
>> > *header,
>> >
>> > header->size += size;
>> > }
>> > +
>> > + if (sample_typ
On Tue, Aug 22, 2017 at 12:03 AM, Jiri Olsa wrote:
>
> On Mon, Aug 21, 2017 at 06:25:45PM -0700, Andi Kleen wrote:
> > On Mon, Aug 21, 2017 at 05:13:29PM -0700, Stephane Eranian wrote:
> > > On Mon, Aug 21, 2017 at 4:02 PM, Andi Kleen wrote:
> > > >
On Mon, Aug 21, 2017 at 4:02 PM, Andi Kleen wrote:
>
> Stephane Eranian writes:
> >
> > To activate, the user must use:
> > $ perf record -a -R
>
> I don't know why you're overloading the existing raw mode?
>
> It has nothing to do with that.
&
and do not add yet another option.
With this patch, it is possible to evaluate the total number
of occurrences of each sampling event even when multiplexing is
active.
Signed-off-by: Stephane Eranian
---
tools/perf/Documentation/perf-record.txt | 2 ++
tools/perf/util/evsel.c | 5
On Thu, Aug 17, 2017 at 8:51 AM, wrote:
> From: Kan Liang
>
> For understanding how the workload maps to memory channels and hardware
> behavior, it's very important to collect address maps with physical
> addresses. For example, 3D XPoint access can only be found by filtering
> the physical add
On Wed, Aug 9, 2017 at 1:42 PM, wrote:
> From: Kan Liang
>
> For understanding how the workload maps to memory channels and hardware
> behavior, it's very important to collect address maps with physical
> addresses. For example, 3D XPoint access can only be found by filtering
> the physical addr
Commit-ID: b3625980a65db6b6b6bbd5790a77ab95ce6397c5
Gitweb: http://git.kernel.org/tip/b3625980a65db6b6b6bbd5790a77ab95ce6397c5
Author: Stephane Eranian
AuthorDate: Thu, 13 Jul 2017 10:35:45 -0700
Committer: Ingo Molnar
CommitDate: Mon, 24 Jul 2017 11:13:17 +0200
perf/x86/intel/uncore
Commit-ID: ba883b4abc9cd837441b01eb9cf8d9196181294d
Gitweb: http://git.kernel.org/tip/ba883b4abc9cd837441b01eb9cf8d9196181294d
Author: Stephane Eranian
AuthorDate: Thu, 13 Jul 2017 10:35:50 -0700
Committer: Ingo Molnar
CommitDate: Mon, 24 Jul 2017 11:13:18 +0200
perf/x86/intel/uncore
Commit-ID: 8aa7b7b4b4a601978672dce6604b9f5630b2eeb8
Gitweb: http://git.kernel.org/tip/8aa7b7b4b4a601978672dce6604b9f5630b2eeb8
Author: Stephane Eranian
AuthorDate: Thu, 13 Jul 2017 10:35:49 -0700
Committer: Ingo Molnar
CommitDate: Mon, 24 Jul 2017 11:13:18 +0200
perf/x86/intel/uncore
On Fri, Jun 16, 2017 at 10:50 AM, Andi Kleen wrote:
>> > Yeah, I think it is easier and more portable, especially on hardware with a
>> > PEBS-like mechanism but no branch buffer (like LBR). FYI, I did do a test
>> > implementation yesterday to evaluate the difficulty.
>> >
>> A more generalized u
On Fri, Jun 16, 2017 at 10:08 AM, Stephane Eranian wrote:
> On Fri, Jun 16, 2017 at 9:06 AM, Andi Kleen wrote:
>> On Thu, Jun 15, 2017 at 11:52:07PM -0700, Stephane Eranian wrote:
>>> Andi,
>>>
>>> On Thu, Jun 15, 2017 at 4:18 PM, Andi Kleen wrote:
>&
On Fri, Jun 16, 2017 at 9:06 AM, Andi Kleen wrote:
> On Thu, Jun 15, 2017 at 11:52:07PM -0700, Stephane Eranian wrote:
>> Andi,
>>
>> On Thu, Jun 15, 2017 at 4:18 PM, Andi Kleen wrote:
>> >> Looking at this approach, the user interface is straightforward,
>&g
Andi,
On Thu, Jun 15, 2017 at 4:18 PM, Andi Kleen wrote:
>> Looking at this approach, the user interface is straightforward,
>> implementation in the x86 code is a bit more hairy because of the way
>> the branch_stack is captured, via the cpuc->lbr_entries. If you assume
>> that SKID_IP cannot be
On Thu, Jun 15, 2017 at 1:20 PM, Stephane Eranian wrote:
> On Thu, Jun 15, 2017 at 1:02 PM, Andi Kleen wrote:
>> On Thu, Jun 15, 2017 at 12:35:39PM -0700, Stephane Eranian wrote:
>>> On Thu, Jun 15, 2017 at 10:23 AM, Andi Kleen wrote:
>>> > On Thu, Jun 15, 2017
On Thu, Jun 15, 2017 at 1:02 PM, Andi Kleen wrote:
> On Thu, Jun 15, 2017 at 12:35:39PM -0700, Stephane Eranian wrote:
>> On Thu, Jun 15, 2017 at 10:23 AM, Andi Kleen wrote:
>> > On Thu, Jun 15, 2017 at 09:44:07AM -0700, Stephane Eranian wrote:
>> >> On Thu, Jun 1
On Thu, Jun 15, 2017 at 10:23 AM, Andi Kleen wrote:
> On Thu, Jun 15, 2017 at 09:44:07AM -0700, Stephane Eranian wrote:
>> On Thu, Jun 15, 2017 at 8:10 AM, Andi Kleen wrote:
>> > On Thu, Jun 15, 2017 at 06:56:24AM -0700, Stephane Eranian wrote:
>> >> This patchs
Hi,
On Thu, Jun 15, 2017 at 9:39 AM, Stephane Eranian wrote:
> On Thu, Jun 15, 2017 at 8:40 AM, Liang, Kan wrote:
>>
>>
>>> This patch adds support for SKID_IP to Intel x86 processors in PEBS mode. In
>>> that case, the off-by-1 IP from PEBS is returned in the
On Thu, Jun 15, 2017 at 8:10 AM, Andi Kleen wrote:
> On Thu, Jun 15, 2017 at 06:56:24AM -0700, Stephane Eranian wrote:
>> This patchs adds a new sample record type called
>> PERF_SAMPLE_SKID_IP. The goal is to record
>> the unmodified interrupted instruction pointer (IP) as
p event
> (attr.precise = 2).
> With the :p event (attr.precise = 1), the skid_ip and ip are the same. Right?
>
Correct, because skid_ip would be equal to the pebs->ip.
> Thanks,
> Kan
>
>>
>> Signed-off-by: Stephane Eranian
>> ---
>> arch/x86/events/
precise=1, the IP would point to
0x42c2f3. It is interesting to collect both IPs in a single run to determine
how often the conditional branch is taken vs. non-taken.
Stephane Eranian (5):
perf/core: add PERF_SAMPLE_SKID_IP record type
perf/x86: add PERF_SAMPLE_SKID_IP support for X86 PEBS
perf
This patch adds support for SKID_IP to Intel x86 processors
in PEBS mode. In that case, the off-by-1 IP from PEBS is returned in
the SKID_IP field.
Signed-off-by: Stephane Eranian
---
arch/x86/events/intel/ds.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/events/intel
may be
different in precise mode depending on the event.
$ perf record --skid-ip .
Signed-off-by: Stephane Eranian
---
tools/perf/Documentation/perf-record.txt | 8
tools/perf/builtin-record.c | 2 ++
2 files changed, 10 insertions(+)
diff --git a/tools/perf
This patch adds a skid_ip field to perf script
to dump the raw value of the PERF_SAMPLE_SKID_IP
field in each sample.
$ perf script -F ip,skid_ip ..
Signed-off-by: Stephane Eranian
---
tools/perf/builtin-script.c | 12 +++-
tools/perf/util/session.c | 2 +-
2 files changed, 12
This patch adds the support code to handle the PERF_SAMPLE_SKID_IP
record type.
Signed-off-by: Stephane Eranian
---
tools/include/uapi/linux/perf_event.h | 4 +++-
tools/perf/perf.h | 1 +
tools/perf/util/event.h | 1 +
tools/perf/util/evsel.c
to the branch instruction itself. Today, it is not possible to
retrieve
both at the same time. This patch makes this possible by specifying
PERF_SAMPLE_IP|PERF_SAMPLE_SKID_IP.
Signed-off-by: Stephane Eranian
---
include/linux/perf_event.h | 2 ++
include/uapi/linux/perf_event.h | 4
Hi,
On Thu, Jun 8, 2017 at 1:15 AM, Peter Zijlstra wrote:
>
> On Wed, Jun 07, 2017 at 04:22:24PM -0700, Andi Kleen wrote:
>
> > diff --git a/include/uapi/linux/perf_event.h
> > b/include/uapi/linux/perf_event.h
> > index b1c0b187acfe..95daade294d7 100644
> > --- a/include/uapi/linux/perf_event.h
On Tue, May 30, 2017 at 9:28 AM, Peter Zijlstra wrote:
> On Tue, May 30, 2017 at 06:51:28AM -0700, Andi Kleen wrote:
>> On Tue, May 30, 2017 at 11:25:23AM +0200, Peter Zijlstra wrote:
>> > On Sun, May 28, 2017 at 01:31:09PM -0700, Stephane Eranian wrote:
>> > > Ultim
On Tue, May 30, 2017 at 2:25 AM, Peter Zijlstra wrote:
> On Sun, May 28, 2017 at 01:31:09PM -0700, Stephane Eranian wrote:
>> Ultimately, I would like to see the watchdog move out of the PMU. That
>> is the only sensible solution.
>> You just need a resource able to interrupt
On Wed, May 24, 2017 at 9:01 AM, Vince Weaver wrote:
>
> On Wed, 24 May 2017, Andi Kleen wrote:
>
> > > Right, I did not even consider the rdpmc, but yeah, you will get a count
> > > that
> > > is not relevant to the user visible event. Unless you fake it using the
> > > time
> > > scaling field
On Mon, May 22, 2017 at 11:39 PM, Peter Zijlstra wrote:
> On Mon, May 22, 2017 at 12:28:26PM -0700, Stephane Eranian wrote:
>> On Mon, May 22, 2017 at 12:23 PM, Peter Zijlstra
>> wrote:
>> > On Mon, May 22, 2017 at 04:55:47PM +, Liang, Kan wrote:
>> >>
&
On Mon, May 22, 2017 at 12:23 PM, Peter Zijlstra wrote:
> On Mon, May 22, 2017 at 04:55:47PM +, Liang, Kan wrote:
>>
>>
>> > On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote:
>> > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index
>> > > 580b60f..e8b2326 10
Andi,
On Fri, May 19, 2017 at 10:06 AM, wrote:
> From: Kan Liang
>
> The NMI watchdog uses either the fixed cycles or a generic cycles
> counter. This causes a lot of conflicts with users of the PMU who want
> to run a full group including the cycles fixed counter, for example the
> --topdown s
Hi,
On Mon, May 22, 2017 at 1:30 AM, Peter Zijlstra wrote:
> On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote:
>> From: Kan Liang
>>
>> The CPU ref_cycles can only be used by one user at the same time,
>> otherwise a "not counted" error will be displaced.
>> [kan]$ sudo pe
Commit-ID: db49a71798a38f3ddf3f3462703328dca39b1ac7
Gitweb: http://git.kernel.org/tip/db49a71798a38f3ddf3f3462703328dca39b1ac7
Author: Stephane Eranian
AuthorDate: Wed, 12 Apr 2017 11:23:01 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 13 Apr 2017 10:40:36 -0300
perf stat
On Tue, Apr 4, 2017 at 10:52 AM, wrote:
> From: Kan Liang
>
> Spurious NMIs will be observed when applying the following command.
>while true ; do sudo perf record -b -a -e
>"cpu/umask=0x01,event=0xcd,ldlat=0x80/pp,cpu/umask=0x03,event=0x0/,
> cpu/umask=0x02,event=0x0/,cycles,branche
On Thu, Mar 23, 2017 at 11:25 AM, wrote:
> From: Kan Liang
>
> Currently, there is no way to measure the time cost in System management
> mode (SMM) by perf.
>
> Intel perfmon supports FREEZE_WHILE_SMM bit in IA32_DEBUGCTL. Once it sets,
> the PMU core counters will freeze on SMI handler. But it
Commit-ID: 88b897a30c525c2eee6e7f16e1e8d0f18830845e
Gitweb: http://git.kernel.org/tip/88b897a30c525c2eee6e7f16e1e8d0f18830845e
Author: Stephane Eranian
AuthorDate: Wed, 15 Mar 2017 10:17:13 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 15 Mar 2017 17:48:37 -0300
perf
Arnaldo,
On Wed, Mar 15, 2017 at 10:44 AM, Arnaldo Carvalho de Melo
wrote:
>
> Em Wed, Mar 15, 2017 at 10:08:27AM -0700, Stephane Eranian escreveu:
> > On Wed, Mar 15, 2017 at 6:58 AM, Arnaldo Carvalho de Melo
> > wrote:
> > > Em Wed, Mar 15, 2017 at 10:50:59AM -030
ks/pid/maps to
actual /proc/pid/task/pid/maps, tasks -> task.
Thanks Arnaldo for catching this.
Signed-off-by: Stephane Eranian
---
tools/perf/util/event.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 4ea7ce7..
On Wed, Mar 15, 2017 at 6:58 AM, Arnaldo Carvalho de Melo
wrote:
> Em Wed, Mar 15, 2017 at 10:50:59AM -0300, Arnaldo Carvalho de Melo escreveu:
>> So, fixing up the "tasks" -> "tasks" we end up with something safe and
>> that avoids this by now
>
> "tasks" -> "task", grrr
>
Oops, yeah, sorry about
herefore we can work around the issue by using /proc/pid/tasks/pid/maps.
This entry does not try to map a vma to stack and is thus much
faster with no loss of functonality.
The proc-map-timeout logic is kept in case user still want some uppre limit.
Signed-off-by: Stephane Eranian
---
tool
Hi,
On Tue, Mar 7, 2017 at 12:04 PM, Luck, Tony wrote:
>> That's all nice and good, but I still have no coherent explanation why
>> measuring across allocation domains makes sense.
>
> Is this in reaction to this one?
>
>>> 5) Put multiple threads into a single measurement group
>
> If we fi
Tony,
On Tue, Feb 7, 2017 at 10:52 AM, Luck, Tony wrote:
> On Tue, Feb 07, 2017 at 12:08:09AM -0800, Stephane Eranian wrote:
>> Hi,
>>
>> I wanted to take a few steps back and look at the overall goals for
>> cache monitoring.
>> From the various threads and d
Hi,
I wanted to take a few steps back and look at the overall goals for
cache monitoring.
>From the various threads and discussion, my understanding is as follows.
I think the design must ensure that the following usage models can be monitored:
- the allocations in your CAT partitions
- the
On Fri, Jan 27, 2017 at 11:18 AM, Arnaldo Carvalho de Melo
wrote:
> Em Fri, Jan 27, 2017 at 10:10:09AM -0800, Stephane Eranian escreveu:
>> On Fri, Jan 27, 2017 at 10:05 AM, Arnaldo Carvalho de Melo
>> wrote:
>> > Em Fri, Jan 27, 2017 at 09:46:55AM -0800, Stephane Erania
On Fri, Jan 27, 2017 at 10:05 AM, Arnaldo Carvalho de Melo
wrote:
> Em Fri, Jan 27, 2017 at 09:46:55AM -0800, Stephane Eranian escreveu:
>> On Fri, Jan 27, 2017 at 9:38 AM, Arnaldo Carvalho de Melo
>> wrote:
>> > Em Fri, Jan 27, 2017 at 12:43:05PM -0300, Arnaldo Carvalh
On Fri, Jan 27, 2017 at 9:38 AM, Arnaldo Carvalho de Melo
wrote:
> Em Fri, Jan 27, 2017 at 12:43:05PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Jan 27, 2017 at 02:07:02PM +0100, Peter Zijlstra escreveu:
>> > Something like the (compile tested only) below might be sufficient to
>> > disa
On Fri, Jan 27, 2017 at 7:43 AM, Arnaldo Carvalho de Melo
wrote:
> Em Fri, Jan 27, 2017 at 02:07:02PM +0100, Peter Zijlstra escreveu:
>> Something like the (compile tested only) below might be sufficient to
>> disambiguate things. It would need a corresponding tools/perf patch of
>> course, but I'
On Thu, Jan 26, 2017 at 3:09 PM, Andres Freund wrote:
> Hi Stephane,
>
>
> On 2017-01-26 14:51:02 -0800, Stephane Eranian wrote:
>> Ok, I think I see the problem now (sorry was slow):
>
> No worries ;)
>
>
>> the timeline is as follows as seen from the user
On Thu, Jan 26, 2017 at 2:38 PM, Andres Freund wrote:
> On 2017-01-26 14:26:12 -0800, Stephane Eranian wrote:
>> On Thu, Jan 26, 2017 at 2:19 PM, Peter Zijlstra wrote:
>> > On Thu, Jan 26, 2017 at 01:00:52PM -0800, Andres Freund wrote:
>> >> The problem is that (q
On Thu, Jan 26, 2017 at 2:19 PM, Peter Zijlstra wrote:
> On Thu, Jan 26, 2017 at 01:00:52PM -0800, Andres Freund wrote:
>> The problem is that (quoted below) without that hack the subsequent
>> mmaps just expand the previous VMAs which leads to perf loosing its
>> (address,range) -> symbol mapping
201 - 300 of 2094 matches
Mail list logo
