On 6/12/15 5:12 AM, Adrian Hunter wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like mmap,
comm and task events) which can be enabled by setting a single
bit. It is
On 6/11/15 8:15 AM, Peter Zijlstra wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like mmap,
comm and task events) which can be enabled by setting a single
bit. It is
On 6/11/15 12:47 PM, Andi Kleen wrote:
Can you elaborate on an example? I don't see how this can happen
reading a maps file. And it does not read maps for all threads only
thread group leaders.
This is with a stress test case that generates lots of small mappings
at very high speed and frees
ping
On 6/5/15 11:42 AM, David Ahern wrote:
Building perf out of kernel tree is currently broken because the
MANIFEST file refers to kernel files that have been removed. With
this patch make perf-targz-src-pkg succeeds as does building perf
using the generated tarfile.
Signed-off-by: David
On 6/11/15 8:06 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Jun 10, 2015 at 03:46:04AM -0400, kan.li...@intel.com escreveu:
perf top reads all threads' /proc/xxx/maps. If there is any threads
which generating a keeping growing huge /proc/xxx/maps, perf will do
infinite loop in
On 6/11/15 12:47 PM, Andi Kleen wrote:
Can you elaborate on an example? I don't see how this can happen
reading a maps file. And it does not read maps for all threads only
thread group leaders.
This is with a stress test case that generates lots of small mappings
at very high speed and frees
On 6/11/15 8:15 AM, Peter Zijlstra wrote:
This new PERF_RECORD_SWITCH event does not have those problems
and it also has a couple of other small advantages. It is
easier to use because it is an auxiliary event (like mmap,
comm and task events) which can be enabled by setting a single
bit. It is
On 6/11/15 8:06 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Jun 10, 2015 at 03:46:04AM -0400, kan.li...@intel.com escreveu:
perf top reads all threads' /proc/xxx/maps. If there is any threads
which generating a keeping growing huge /proc/xxx/maps, perf will do
infinite loop in
ping
On 6/5/15 11:42 AM, David Ahern wrote:
Building perf out of kernel tree is currently broken because the
MANIFEST file refers to kernel files that have been removed. With
this patch make perf-targz-src-pkg succeeds as does building perf
using the generated tarfile.
Signed-off-by: David
On 6/10/15 12:10 PM, Jiri Olsa wrote:
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index efc4d420f12e..3ababdb83aad 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -290,6 +290,7 @@ static int process_counter(struct perf_evsel *counter)
int
On 6/10/15 12:10 PM, Jiri Olsa wrote:
Currently all the -p option PID arguments tasks values
get aggregated and printed as single values.
Adding --per-tasks option to print values per task.
$ perf stat -e cycles,instructions --per-task -p 12451,16173
^C
Performance counter stats for
On 6/10/15 12:10 PM, Jiri Olsa wrote:
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index efc4d420f12e..3ababdb83aad 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -290,6 +290,7 @@ static int process_counter(struct perf_evsel *counter)
int
On 6/10/15 12:10 PM, Jiri Olsa wrote:
Currently all the -p option PID arguments tasks values
get aggregated and printed as single values.
Adding --per-tasks option to print values per task.
$ perf stat -e cycles,instructions --per-task -p 12451,16173
^C
Performance counter stats for
On 6/9/15 2:02 PM, Vince Weaver wrote:
# ls/sys/kernel/debug/tracing/events/irq/irq_handler_entry/
enable filter format id trigger
# perf list
[ Tracepoints not available: No such file or directory ]
strace shows
statfs("/sys/kernel/debug/tracing/events", {f_type=0x74726163,
On 6/9/15 1:51 PM, Vince Weaver wrote:
# perf record -e irq:irq_handler_entry --filter irq==28 -e irq:softirq_entry
--filter vec==6 -a -- sleep 5
invalid or unsupported event: 'irq:irq_handler_entry'
Run 'perf list' for a list of valid events
perf list doesn't show any tracepoint events,
On 6/9/15 12:30 PM, Vince Weaver wrote:
Hello
I've been working on documenting the PERF_EVENT_IOC_SET_FILTER ioctl.
I've been trying for the past 2 days and have been unable to get any
result except EINVAL.
Does anyone ever use this ioctl? Does anyone know how to use this ioctl?
yes and
On 6/9/15 1:51 PM, Vince Weaver wrote:
# perf record -e irq:irq_handler_entry --filter irq==28 -e irq:softirq_entry
--filter vec==6 -a -- sleep 5
invalid or unsupported event: 'irq:irq_handler_entry'
Run 'perf list' for a list of valid events
perf list doesn't show any tracepoint events,
On 6/9/15 2:02 PM, Vince Weaver wrote:
# ls/sys/kernel/debug/tracing/events/irq/irq_handler_entry/
enable filter format id trigger
# perf list
[ Tracepoints not available: No such file or directory ]
strace shows
statfs(/sys/kernel/debug/tracing/events, {f_type=0x74726163,
On 6/9/15 12:30 PM, Vince Weaver wrote:
Hello
I've been working on documenting the PERF_EVENT_IOC_SET_FILTER ioctl.
I've been trying for the past 2 days and have been unable to get any
result except EINVAL.
Does anyone ever use this ioctl? Does anyone know how to use this ioctl?
yes and
Building perf out of kernel tree is currently broken because the
MANIFEST file refers to kernel files that have been removed. With
this patch make perf-targz-src-pkg succeeds as does building perf
using the generated tarfile.
Signed-off-by: David Ahern
---
tools/perf/MANIFEST |4
1
Building perf out of kernel tree is currently broken because the
MANIFEST file refers to kernel files that have been removed. With
this patch make perf-targz-src-pkg succeeds as does building perf
using the generated tarfile.
Signed-off-by: David Ahern david.ah...@oracle.com
---
tools/perf
On 5/28/15 6:19 AM, Peter Zijlstra wrote:
On Thu, 2015-05-28 at 13:49 +0200, Ingo Molnar wrote:
What's the biggest you've seen?
Wikipedia here: http://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29
Tell us HSW-E[PX] have 18 cores 36 thread SKUs.
But yes, what Mike says, its bound
On 5/28/15 6:19 AM, Peter Zijlstra wrote:
On Thu, 2015-05-28 at 13:49 +0200, Ingo Molnar wrote:
What's the biggest you've seen?
Wikipedia here: http://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29
Tell us HSW-E[PX] have 18 cores 36 thread SKUs.
But yes, what Mike says, its bound
On 5/17/15 6:30 PM, Namhyung Kim wrote:
The current code assumes that the number of index item and cpu are
matched so it creates that number of threads. But it's not the case
of non-system-wide session or data came from different machine.
Just creates threads at most number of online cpus and
On 5/19/15 8:08 AM, Arnaldo Carvalho de Melo wrote:
Em Thu, Jan 29, 2015 at 02:03:46PM +0100, Martin Liška escreveu:
Newly introduced options usedfull for off-box usage:
New useful options for off-box usage:
--objdump-prefix: specify prefix to add to the absolute paths
where
On 5/19/15 8:08 AM, Arnaldo Carvalho de Melo wrote:
Em Thu, Jan 29, 2015 at 02:03:46PM +0100, Martin Liška escreveu:
Newly introduced options usedfull for off-box usage:
New useful options for off-box usage:
--objdump-prefix: specify prefix to add to the absolute paths
where
On 5/17/15 6:30 PM, Namhyung Kim wrote:
The current code assumes that the number of index item and cpu are
matched so it creates that number of threads. But it's not the case
of non-system-wide session or data came from different machine.
Just creates threads at most number of online cpus and
On 5/9/15 9:19 AM, Namhyung Kim wrote:
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 896672badba3..610e1e2cd035 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -34,7 +34,8 @@ OPTIONS
On 5/9/15 9:19 AM, Namhyung Kim wrote:
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 896672badba3..610e1e2cd035 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -34,7 +34,8 @@ OPTIONS
On 5/8/15 8:27 AM, Will Deacon wrote:
On Fri, May 08, 2015 at 03:25:13PM +0100, Peter Zijlstra wrote:
On Fri, May 08, 2015 at 03:21:08PM +0100, Will Deacon wrote:
Wouldn't it be better to go the other way, and use compiler builtins for
the memory barriers instead of relying on the kernel? It
On 5/8/15 8:27 AM, Will Deacon wrote:
On Fri, May 08, 2015 at 03:25:13PM +0100, Peter Zijlstra wrote:
On Fri, May 08, 2015 at 03:21:08PM +0100, Will Deacon wrote:
Wouldn't it be better to go the other way, and use compiler builtins for
the memory barriers instead of relying on the kernel? It
Commit-ID: 6b1a27520f990700d0dd23976afd8992bf659698
Gitweb: http://git.kernel.org/tip/6b1a27520f990700d0dd23976afd8992bf659698
Author: David Ahern
AuthorDate: Tue, 14 Apr 2015 13:49:33 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 29 Apr 2015 10:37:44 -0300
perf kmem: Fix
On 5/5/15 3:53 PM, Rabin Vincent wrote:
The commands above will identify the sys_write which takes time but only
provide the stacktrace at the entry and exit of the syscall, but this do
not show why the process blocked or what it did inside the system call.
So a way to get what is required for
Commit-ID: 6b1a27520f990700d0dd23976afd8992bf659698
Gitweb: http://git.kernel.org/tip/6b1a27520f990700d0dd23976afd8992bf659698
Author: David Ahern david.ah...@oracle.com
AuthorDate: Tue, 14 Apr 2015 13:49:33 -0400
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Wed, 29
On 5/5/15 3:53 PM, Rabin Vincent wrote:
The commands above will identify the sys_write which takes time but only
provide the stacktrace at the entry and exit of the syscall, but this do
not show why the process blocked or what it did inside the system call.
So a way to get what is required for
Commit-ID: 4ad1f4300e3bddf63109aa63cfb2d37e8585ecc7
Gitweb: http://git.kernel.org/tip/4ad1f4300e3bddf63109aa63cfb2d37e8585ecc7
Author: David Ahern
AuthorDate: Tue, 14 Apr 2015 13:49:33 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 24 Apr 2015 12:44:47 -0300
perf kmem: Fix
Commit-ID: 4ad1f4300e3bddf63109aa63cfb2d37e8585ecc7
Gitweb: http://git.kernel.org/tip/4ad1f4300e3bddf63109aa63cfb2d37e8585ecc7
Author: David Ahern david.ah...@oracle.com
AuthorDate: Tue, 14 Apr 2015 13:49:33 -0400
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Fri, 24
On 4/27/15 10:26 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Apr 24, 2015 at 11:21:54AM -0600, David Ahern escreveu:
On 4/24/15 10:22 AM, Will Deacon wrote:
I don't have a SPARC machine to hand, but we could check that the character
immediately following "CPU" is a number [0-9]
On 4/27/15 10:26 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Apr 24, 2015 at 11:21:54AM -0600, David Ahern escreveu:
On 4/24/15 10:22 AM, Will Deacon wrote:
I don't have a SPARC machine to hand, but we could check that the character
immediately following CPU is a number [0-9].
I have access
On 4/25/15 8:05 AM, Yunlong Song wrote:
On 2015/4/24 21:58, David Ahern wrote:
On 4/24/15 7:31 AM, Yunlong Song wrote:
Now we are profiling the performance of ext4 and f2fs on an eMMC card with
iozone,
we find a case that ext4 is better than f2fs in random write under the test of
"iozo
On 4/25/15 8:05 AM, Yunlong Song wrote:
On 2015/4/24 21:58, David Ahern wrote:
On 4/24/15 7:31 AM, Yunlong Song wrote:
Now we are profiling the performance of ext4 and f2fs on an eMMC card with
iozone,
we find a case that ext4 is better than f2fs in random write under the test of
iozone -s
On 4/24/15 11:00 AM, Davidlohr Bueso wrote:
This bug, while perhaps suggesting missing wakeups in kernel futex
code, is merely a consequence of the crappy FUTEX_CMP_REQUEUE man
page, incorrectly mentioning that the number of requeued tasks is
in fact returned, not the wakeups. This patch
On 4/24/15 10:22 AM, Will Deacon wrote:
I don't have a SPARC machine to hand, but we could check that the character
immediately following "CPU" is a number [0-9].
I have access to 1 or 2 or ...
Yes, it needs start with CPU and be all caps (there are other Cpu lines)
and a cpu number follows:
On 4/24/15 7:31 AM, Yunlong Song wrote:
Now we are profiling the performance of ext4 and f2fs on an eMMC card with
iozone,
we find a case that ext4 is better than f2fs in random write under the test of
"iozone -s 262144 -r 64 -i 0 -i 2". We want to analyze the I/O delay of the two
file systems.
On 4/23/15 6:38 PM, Vinson Lee wrote:
Hi.
4.0-rc1 commit 0d68bc92c48167130b61b449f08be27dc862dba2 "perf kmem:
Analyze page allocator events also" introduced a build error with
older toolchains.
For example, this build errors occurs on CentOS 6.
CC builtin-kmem.o
cc1: warnings being
On 4/24/15 7:31 AM, Yunlong Song wrote:
[Profiling Problem]
Although perf can record the events (with call stack) of a specified pid, e.g.
using
"perf record -g iozone -s 262144 -r 64 -i 0 -i 2". But we find iozone is
interrupted
That command tells perf to *only* collect data for iozone.
On 4/23/15 6:38 PM, Vinson Lee wrote:
Hi.
4.0-rc1 commit 0d68bc92c48167130b61b449f08be27dc862dba2 perf kmem:
Analyze page allocator events also introduced a build error with
older toolchains.
For example, this build errors occurs on CentOS 6.
CC builtin-kmem.o
cc1: warnings being
On 4/24/15 7:31 AM, Yunlong Song wrote:
[Profiling Problem]
Although perf can record the events (with call stack) of a specified pid, e.g.
using
perf record -g iozone -s 262144 -r 64 -i 0 -i 2. But we find iozone is
interrupted
That command tells perf to *only* collect data for iozone. This
On 4/24/15 7:31 AM, Yunlong Song wrote:
Now we are profiling the performance of ext4 and f2fs on an eMMC card with
iozone,
we find a case that ext4 is better than f2fs in random write under the test of
iozone -s 262144 -r 64 -i 0 -i 2. We want to analyze the I/O delay of the two
file systems.
On 4/24/15 11:00 AM, Davidlohr Bueso wrote:
This bug, while perhaps suggesting missing wakeups in kernel futex
code, is merely a consequence of the crappy FUTEX_CMP_REQUEUE man
page, incorrectly mentioning that the number of requeued tasks is
in fact returned, not the wakeups. This patch
On 4/24/15 10:22 AM, Will Deacon wrote:
I don't have a SPARC machine to hand, but we could check that the character
immediately following CPU is a number [0-9].
I have access to 1 or 2 or ...
Yes, it needs start with CPU and be all caps (there are other Cpu lines)
and a cpu number follows:
On 4/23/15 5:29 AM, Will Deacon wrote:
Hi all,
Commit 6428c59a97de ("perf tools: Set JOBS based on CPU or processor")
causes weird behaviour on arm/arm64 platforms because we use the "CPU"
prefix for things like:
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part
On 4/23/15 8:04 AM, Will Deacon wrote:
From 28740111e81aa9247bf48e3125dc43cc31d94e6f Mon Sep 17 00:00:00 2001
From: Will Deacon
Date: Thu, 23 Apr 2015 15:00:16 +0100
Subject: [PATCH] tools: perf: use getconf to determine number of online CPUs
Parsing /proc/cpuinfo is a fiddly, arch-dependent
On 4/23/15 8:04 AM, Will Deacon wrote:
From 28740111e81aa9247bf48e3125dc43cc31d94e6f Mon Sep 17 00:00:00 2001
From: Will Deacon will.dea...@arm.com
Date: Thu, 23 Apr 2015 15:00:16 +0100
Subject: [PATCH] tools: perf: use getconf to determine number of online CPUs
Parsing /proc/cpuinfo is a
On 4/23/15 5:29 AM, Will Deacon wrote:
Hi all,
Commit 6428c59a97de (perf tools: Set JOBS based on CPU or processor)
causes weird behaviour on arm/arm64 platforms because we use the CPU
prefix for things like:
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part:
ng the buffer read-only. Is that correct?
>
>Correct, but I'm sure we could still add something (if it doesn't
>already exist) to have userspace write into the buffer. Ftrace has that
>with the trace_marker file.
There is something in the works, I guess Pawell Moll (sp) was workin
the buffer read-only. Is that correct?
Correct, but I'm sure we could still add something (if it doesn't
already exist) to have userspace write into the buffer. Ftrace has that
with the trace_marker file.
There is something in the works, I guess Pawell Moll (sp) was working on it, and
David Ahern (CCed
On 4/20/15 3:25 PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu:
On Wed, 15 Apr 2015 15:09:27 -0300
Arnaldo Carvalho de Melo wrote:
If it is strictly an enum, i.e. no holes and just by looking at the
"format" file above I don't see how it
On 4/20/15 3:25 PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu:
On Wed, 15 Apr 2015 15:09:27 -0300
Arnaldo Carvalho de Melo a...@kernel.org wrote:
If it is strictly an enum, i.e. no holes and just by looking at the
format file above I
On 4/18/15 11:33 AM, Namhyung Kim wrote:
+It might confusing that the sum of the all children overhead exceeds
+100%. But with this enabled, users can find which function has most
+overhead even if samples are spread over the children.
Can you add more detail on why the sum can exceed 100%?
On 4/18/15 11:33 AM, Namhyung Kim wrote:
+It might confusing that the sum of the all children overhead exceeds
+100%. But with this enabled, users can find which function has most
+overhead even if samples are spread over the children.
Can you add more detail on why the sum can exceed 100%?
Hi Steve:
I was hoping you could provide points on how to get access to an
interpreted field in a tracepoint within perf.
This is an example of the tracepoint:
# cat /sys/kernel/debug/tracing/events/irq/softirq_exit/format
name: softirq_exit
ID: 99
format:
field:unsigned short
Hi Peter:
On 4/15/15 3:41 AM, Peter Zijlstra wrote:
Thomas stumbled over the hrtimer_forward_now() in
perf_event_mux_interval_ms_store() and noticed its broken-ness.
You cannot just change the expiry time of an active timer, it will
destroy the red-black tree order and cause havoc.
Change it
Hi Peter:
On 4/15/15 3:41 AM, Peter Zijlstra wrote:
Thomas stumbled over the hrtimer_forward_now() in
perf_event_mux_interval_ms_store() and noticed its broken-ness.
You cannot just change the expiry time of an active timer, it will
destroy the red-black tree order and cause havoc.
Change it
Hi Steve:
I was hoping you could provide points on how to get access to an
interpreted field in a tracepoint within perf.
This is an example of the tracepoint:
# cat /sys/kernel/debug/tracing/events/irq/softirq_exit/format
name: softirq_exit
ID: 99
format:
field:unsigned short
ion ‘perf_evsel__process_page_free_event’:
builtin-kmem.c:431: error: declaration of ‘stat’ shadows a global
declaration
/usr/include/sys/stat.h:455: error: shadowed declaration is here
Rename local variable to pstat to avoid the name conflict.
Signed-off-by: David Ahern
---
tools/perf/buil
: In function ‘perf_evsel__process_page_free_event’:
builtin-kmem.c:431: error: declaration of ‘stat’ shadows a global
declaration
/usr/include/sys/stat.h:455: error: shadowed declaration is here
Rename local variable to pstat to avoid the name conflict.
Signed-off-by: David Ahern david.ah
Commit-ID: 7b8283b56d9fb36106ff1c459dfd399a20bd374d
Gitweb: http://git.kernel.org/tip/7b8283b56d9fb36106ff1c459dfd399a20bd374d
Author: David Ahern
AuthorDate: Tue, 7 Apr 2015 09:20:37 -0600
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 10 Apr 2015 11:29:20 -0300
perf evlist
Commit-ID: 1060ab857f64f33a9445881fd31fa91470aeb622
Gitweb: http://git.kernel.org/tip/1060ab857f64f33a9445881fd31fa91470aeb622
Author: David Ahern
AuthorDate: Thu, 9 Apr 2015 16:15:46 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 10 Apr 2015 10:13:58 -0300
perf tools: Fix
Commit-ID: 7764a385f60bd200304a33124bdb4e684caeabdf
Gitweb: http://git.kernel.org/tip/7764a385f60bd200304a33124bdb4e684caeabdf
Author: David Ahern
AuthorDate: Thu, 9 Apr 2015 12:48:27 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 10 Apr 2015 10:10:55 -0300
perf tools: Fix
Commit-ID: 1060ab857f64f33a9445881fd31fa91470aeb622
Gitweb: http://git.kernel.org/tip/1060ab857f64f33a9445881fd31fa91470aeb622
Author: David Ahern david.ah...@oracle.com
AuthorDate: Thu, 9 Apr 2015 16:15:46 -0400
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Fri, 10 Apr
Commit-ID: 7764a385f60bd200304a33124bdb4e684caeabdf
Gitweb: http://git.kernel.org/tip/7764a385f60bd200304a33124bdb4e684caeabdf
Author: David Ahern david.ah...@oracle.com
AuthorDate: Thu, 9 Apr 2015 12:48:27 -0400
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Fri, 10 Apr
Commit-ID: 7b8283b56d9fb36106ff1c459dfd399a20bd374d
Gitweb: http://git.kernel.org/tip/7b8283b56d9fb36106ff1c459dfd399a20bd374d
Author: David Ahern dsah...@gmail.com
AuthorDate: Tue, 7 Apr 2015 09:20:37 -0600
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Fri, 10 Apr 2015
on x86_64.
Signed-off-by: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
---
tools/perf/util/header.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index e38cf62..45b7e72 100644
--- a/tools/perf/util/header.c
+++ b
On 4/9/15 11:05 AM, Don Zickus wrote:
On Thu, Apr 09, 2015 at 12:48:27PM -0400, David Ahern wrote:
>Commit ca6c41c59b9 sets the ppid based on what is read from the
>/proc/pid/status file when synthesizing fork events. This is correct
>thing to do for new processes but not threads of
all sub-threads in a process).
Reported-by: Arnaldo Carvalho de Melo
Signed-off-by: David Ahern
Cc: Don Zickus
---
tools/perf/util/event.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 186929a
all sub-threads in a process).
Reported-by: Arnaldo Carvalho de Melo arnaldo.m...@gmail.com
Signed-off-by: David Ahern david.ah...@oracle.com
Cc: Don Zickus dzic...@redhat.com
---
tools/perf/util/event.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools
on x86_64.
Signed-off-by: David Ahern david.ah...@oracle.com
Cc: Jiri Olsa jo...@kernel.org
Cc: Namhyung Kim namhy...@kernel.org
---
tools/perf/util/header.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index
On 4/9/15 11:05 AM, Don Zickus wrote:
On Thu, Apr 09, 2015 at 12:48:27PM -0400, David Ahern wrote:
Commit ca6c41c59b9 sets the ppid based on what is read from the
/proc/pid/status file when synthesizing fork events. This is correct
thing to do for new processes but not threads of a process. Fix
On 4/8/15 7:45 AM, Arnaldo Carvalho de Melo wrote:
I also noticed that if I set /proc/sys/kernel/perf_event_paranoid to -1
to run it as !root, then the problem "goes away", which I think probably
is explained by, as !root, not being able to parse some of the /proc
files for existing threads and
On 4/8/15 7:45 AM, Arnaldo Carvalho de Melo wrote:
I also noticed that if I set /proc/sys/kernel/perf_event_paranoid to -1
to run it as !root, then the problem goes away, which I think probably
is explained by, as !root, not being able to parse some of the /proc
files for existing threads and
On 4/7/15 5:41 PM, David Ahern wrote:
what happened to this patch? not in your core or urgent branches and
perf-script is still bombing
d'oh. never mind; user error.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
what happened to this patch? not in your core or urgent branches and
perf-script is still bombing
On 3/31/15 7:36 AM, David Ahern wrote:
On 3/31/15 6:59 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Mar 30, 2015 at 08:45:33PM -0300, Arnaldo Carvalho de Melo
escreveu:
Em Mon, Mar 30, 2015 at 04
fails to compile on RHEL6/CentOS6/OL6 ...
On 4/7/15 10:41 AM, Arnaldo Carvalho de Melo wrote:
+/*
+ * Doesn't appear to have made it into userspace so define here if missing.
+ */
+#ifndef CLOCK_TAI
+#define CLOCK_TAI 11
+#endif
+
+static const struct clockid_map clockids[] = {
+ /*
On 3/31/15 7:46 AM, Yunlong Song wrote:
---
tools/perf/builtin-sched.c | 31 ++-
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 3261300..5ab58c6 100644
--- a/tools/perf/builtin-sched.c
data_head and data_tail are defined as __u64 in linux/perf_event.h,
but perf userspace uses int and unsigned int. Convert all references
to u64 for consistency.
Signed-off-by: David Ahern
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
On 3/31/15 7:46 AM, Yunlong Song wrote:
---
tools/perf/builtin-sched.c | 31 ++-
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 3261300..5ab58c6 100644
--- a/tools/perf/builtin-sched.c
data_head and data_tail are defined as __u64 in linux/perf_event.h,
but perf userspace uses int and unsigned int. Convert all references
to u64 for consistency.
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jiri
fails to compile on RHEL6/CentOS6/OL6 ...
On 4/7/15 10:41 AM, Arnaldo Carvalho de Melo wrote:
+/*
+ * Doesn't appear to have made it into userspace so define here if missing.
+ */
+#ifndef CLOCK_TAI
+#define CLOCK_TAI 11
+#endif
+
+static const struct clockid_map clockids[] = {
+ /*
what happened to this patch? not in your core or urgent branches and
perf-script is still bombing
On 3/31/15 7:36 AM, David Ahern wrote:
On 3/31/15 6:59 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Mar 30, 2015 at 08:45:33PM -0300, Arnaldo Carvalho de Melo
escreveu:
Em Mon, Mar 30, 2015 at 04
On 4/7/15 5:41 PM, David Ahern wrote:
what happened to this patch? not in your core or urgent branches and
perf-script is still bombing
d'oh. never mind; user error.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On 3/31/15 3:13 AM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
On Mon, Mar 30, 2015 at 10:43:14AM +0200, Mike Galbraith wrote:
I think it would be a good thing if we can get away with it, but I
also think you could safely bet your life that somebody will
squeak.
The thing I worry most
On 3/31/15 3:13 AM, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Mon, Mar 30, 2015 at 10:43:14AM +0200, Mike Galbraith wrote:
I think it would be a good thing if we can get away with it, but I
also think you could safely bet your life that somebody will
squeak.
The
Commit-ID: ca6c41c59b964d362823e80442e9e32c31106b29
Gitweb: http://git.kernel.org/tip/ca6c41c59b964d362823e80442e9e32c31106b29
Author: David Ahern
AuthorDate: Mon, 30 Mar 2015 14:35:58 -0600
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 31 Mar 2015 17:52:30 -0300
perf tools
Commit-ID: 5aa0b030e8d29d6719c144818814b519cfcb105c
Gitweb: http://git.kernel.org/tip/5aa0b030e8d29d6719c144818814b519cfcb105c
Author: David Ahern
AuthorDate: Mon, 30 Mar 2015 14:35:57 -0600
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 31 Mar 2015 17:52:30 -0300
perf tools
Commit-ID: 5aa0b030e8d29d6719c144818814b519cfcb105c
Gitweb: http://git.kernel.org/tip/5aa0b030e8d29d6719c144818814b519cfcb105c
Author: David Ahern dsah...@gmail.com
AuthorDate: Mon, 30 Mar 2015 14:35:57 -0600
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Tue, 31 Mar
Commit-ID: ca6c41c59b964d362823e80442e9e32c31106b29
Gitweb: http://git.kernel.org/tip/ca6c41c59b964d362823e80442e9e32c31106b29
Author: David Ahern dsah...@gmail.com
AuthorDate: Mon, 30 Mar 2015 14:35:58 -0600
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Tue, 31 Mar
On 3/31/15 4:38 PM, Yinghai Lu wrote:
On Tue, Mar 31, 2015 at 3:29 PM, David Ahern wrote:
Please check attached three patches on top of current linus tree.
new log. Same as before -- PCI_DEBUG, ignore_loglevel ofpci_debug=1
Good, it is clean now.
Yes. You can add a Tested-by to all 3
On 3/31/15 2:25 PM, Arnaldo Carvalho de Melo wrote:
Humm, we already have an rb_tree for each task, its called
machine->threads, and it has struct thread instances, that in turn have
a ->priv point, can't it be used here?
I think that would require a lot of churn to the existing code. The
On 3/31/15 10:53 AM, Yinghai Lu wrote:
On Mon, Mar 30, 2015 at 9:10 PM, David Ahern wrote:
On 3/30/15 7:06 PM, Yinghai Lu wrote:
To make sure I am on the same page: these are a new round of patches? clear
out the old, apply these?
Clear out the old and apply these new ones.
I take DaveM's
801 - 900 of 3566 matches
Mail list logo
