On 3/25/15 6:22 AM, Joe Mario wrote:
We ran "time perf mem record -a -e cpu/mem-loads,ldlat=50/pp -e
cpu/mem-stores/pp sleep 10" on a system that was running SPECjbb2013 in
the background. There were about 10,000 java threads with about 500 to
800 in a runnable state at any given time. We ran
-by: David Ahern
Cc: Don Zickus
Cc: Joe Mario
Cc: Jiri Olsa
---
v2:
- removed loop in place of 1 read and processing a buffer
tools/perf/util/event.c | 178 ++--
1 file changed, 110 insertions(+), 68 deletions(-)
diff --git a/tools/perf/util/event.c b
On 3/25/15 7:24 AM, Arnaldo Carvalho de Melo wrote:
So it starts when there are tons of threads in the system, for which
synthezing from /proc will have to take place, without looking again at
that patch, I can't think about what would be a problem :-\
3 extra lines are read from
On 3/25/15 6:14 AM, Arnaldo Carvalho de Melo wrote:
If David doesn't come up with something I'll probably will, as making
'trace' use the ordered_samples, like 'perf top' does (initially with
some arbitrary reasonable poll timeout value), is a low hanging fruit to
get those multi-CPU tracepoints
On 3/25/15 6:38 AM, Jiri Olsa wrote:
On Tue, Mar 24, 2015 at 12:09:48PM -0400, David Ahern wrote:
Record currently wakes up based on watermarks to read events from the mmaps and
write them out to the file. The result is a file that can have large blocks of
events per mmap before a finished
On 3/25/15 7:24 AM, Arnaldo Carvalho de Melo wrote:
So it starts when there are tons of threads in the system, for which
synthezing from /proc will have to take place, without looking again at
that patch, I can't think about what would be a problem :-\
3 extra lines are read from
On 3/25/15 6:14 AM, Arnaldo Carvalho de Melo wrote:
If David doesn't come up with something I'll probably will, as making
'trace' use the ordered_samples, like 'perf top' does (initially with
some arbitrary reasonable poll timeout value), is a low hanging fruit to
get those multi-CPU tracepoints
On 3/25/15 6:38 AM, Jiri Olsa wrote:
On Tue, Mar 24, 2015 at 12:09:48PM -0400, David Ahern wrote:
Record currently wakes up based on watermarks to read events from the mmaps and
write them out to the file. The result is a file that can have large blocks of
events per mmap before a finished
-by: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Joe Mario jma...@redhat.com
Cc: Jiri Olsa jo...@redhat.com
---
v2:
- removed loop in place of 1 read and processing a buffer
tools/perf/util/event.c | 178 ++--
1 file changed, 110
On 3/25/15 6:22 AM, Joe Mario wrote:
We ran time perf mem record -a -e cpu/mem-loads,ldlat=50/pp -e
cpu/mem-stores/pp sleep 10 on a system that was running SPECjbb2013 in
the background. There were about 10,000 java threads with about 500 to
800 in a runnable state at any given time. We ran
On 3/25/15 1:15 PM, Don Zickus wrote:
On Wed, Mar 25, 2015 at 10:51:10AM -0600, David Ahern wrote:
363b785f38 added synthesized fork events and set a thread's parent id
to itself. Since we are already processing /proc/pid/status the ppid
can be determined properly. Make it so.
Performance
On 3/25/15 2:41 PM, Carl E. Love wrote:
I do not fine the directory tools/build in the linux kernel tree. I am
wondering if the Build file and the tools/build directory might be part
of your source tree build environment?
you want to use acme's perf/core branch from
On 3/25/15 6:57 PM, Stephane Eranian wrote:
Im on tip.git and at commit:
f05bf44 Merge branch 'perf/core'
I had to do this to get the features-tests to work. This setup keeps
changing on me.
perf patches go through Arnaldo, so new patch sets like this should be
against acme's tree, perf/core
On 3/24/15 3:57 PM, Arnaldo Carvalho de Melo wrote:
With the patch below, that leaves printing something, using whatever UI, to the
tool, acceptable?
I keep forgetting about the python bindings.
Your patch serves the purpose. Thanks, Arnaldo.
--
To unsubscribe from this list: send the line
On 3/24/15 3:15 PM, Arnaldo Carvalho de Melo wrote:
/me scratches head, should be missing something embarassingly simple :-/
ptr = sample->raw_data + field->offset;
raw_data is *guaranteed* to be misaligned. From kernel/events/core.c:
struct {
On 3/24/15 2:10 PM, Don Zickus wrote:
He does this with and without the patch. The difference is usually over 50%
extra time with the patch for both the record timings and report timings.:-(
I find that shocking. The patch only populates ppid and ptid with a
value read from the file that is
iltin-timechart.c:569
Another extended load on unaligned pointer. As before fix by copying to
a temporary variable using memcpy.
Signed-off-by: David Ahern
---
tools/perf/util/evsel.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/
Commit-ID: e03eaa400cf8b8bded86cc5c41018a1c69152f16
Gitweb: http://git.kernel.org/tip/e03eaa400cf8b8bded86cc5c41018a1c69152f16
Author: David Ahern
AuthorDate: Tue, 24 Mar 2015 09:52:41 -0600
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 24 Mar 2015 13:02:46 -0300
perf tools
Commit-ID: 6b1f342354d45c651cabd2ae0f61f55846f33e10
Gitweb: http://git.kernel.org/tip/6b1f342354d45c651cabd2ae0f61f55846f33e10
Author: David Ahern
AuthorDate: Tue, 24 Mar 2015 09:51:57 -0600
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 24 Mar 2015 13:01:54 -0300
perf diff: Add
On 3/24/15 10:12 AM, Ingo Molnar wrote:
* David Ahern wrote:
Record currently wakes up based on watermarks to read events from
the mmaps and write them out to the file. The result is a file that
can have large blocks of events per mmap before a finished round
event is added to the stream
Use of a bad filter currently generates the message:
Error: failed to set filter with 22 (Invalid argument)
Add the event name to make it clear to which event the filter
failed to apply:
Error: Failed to set filter on event sched:sg_lb_stats: 22: Invalid argument
Signed-off-by: David Ahern
Number of JOBS to use is set automatically to the number of processors found
in /proc/cpuinfo. SPARC uses 'CPU' lines rather than 'processor'. Update the
check in perf's Makefile to work for SPARC.
Signed-off-by: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
---
tools/perf
side.
Signed-off-by: David Ahern
Cc: Ingo Molnar
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Stephane Eranian
Cc: Adrian Hunter
---
tools/perf/Documentation/perf-record.txt | 6 ++
tools/perf/builtin-record.c | 5 -
tools/perf/perf.h
SPARC based systems currently support up to 1024 cpus (e.g. T5-8).
Allow perf to work on those systems.
Signed-off-by: David Ahern
---
tools/perf/perf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index ee847c8af668..77c8857da123
perf record and top already allow a user to specify a csv of
pids and/or tids of tasks to collect data. Add those options
to the report and script analysis commands to only consider
samples related to the given pids/tids. This is also inline
with the existing comm option.
Signed-off-by: David
Required for off-box analysis to convert kernel addresses.
Signed-off-by: David Ahern
Cc: Jiri Olsa
---
tools/perf/Documentation/perf-diff.txt | 3 +++
tools/perf/builtin-diff.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/tools/perf/Documentation/perf-diff.txt
b/tools
On 3/24/15 3:57 PM, Arnaldo Carvalho de Melo wrote:
With the patch below, that leaves printing something, using whatever UI, to the
tool, acceptable?
I keep forgetting about the python bindings.
Your patch serves the purpose. Thanks, Arnaldo.
--
To unsubscribe from this list: send the line
On 3/24/15 3:15 PM, Arnaldo Carvalho de Melo wrote:
/me scratches head, should be missing something embarassingly simple :-/
ptr = sample-raw_data + field-offset;
raw_data is *guaranteed* to be misaligned. From kernel/events/core.c:
struct {
perf record and top already allow a user to specify a csv of
pids and/or tids of tasks to collect data. Add those options
to the report and script analysis commands to only consider
samples related to the given pids/tids. This is also inline
with the existing comm option.
Signed-off-by: David
Required for off-box analysis to convert kernel addresses.
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
---
tools/perf/Documentation/perf-diff.txt | 3 +++
tools/perf/builtin-diff.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/tools/perf
side.
Signed-off-by: David Ahern david.ah...@oracle.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Jiri Olsa jo...@kernel.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Stephane Eranian eran...@google.com
Cc: Adrian Hunter
Number of JOBS to use is set automatically to the number of processors found
in /proc/cpuinfo. SPARC uses 'CPU' lines rather than 'processor'. Update the
check in perf's Makefile to work for SPARC.
Signed-off-by: David Ahern david.ah...@oracle.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jiri Olsa jo
Use of a bad filter currently generates the message:
Error: failed to set filter with 22 (Invalid argument)
Add the event name to make it clear to which event the filter
failed to apply:
Error: Failed to set filter on event sched:sg_lb_stats: 22: Invalid argument
Signed-off-by: David Ahern
SPARC based systems currently support up to 1024 cpus (e.g. T5-8).
Allow perf to work on those systems.
Signed-off-by: David Ahern david.ah...@oracle.com
---
tools/perf/perf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index
Commit-ID: 6b1f342354d45c651cabd2ae0f61f55846f33e10
Gitweb: http://git.kernel.org/tip/6b1f342354d45c651cabd2ae0f61f55846f33e10
Author: David Ahern dsah...@gmail.com
AuthorDate: Tue, 24 Mar 2015 09:51:57 -0600
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Tue, 24 Mar
Commit-ID: e03eaa400cf8b8bded86cc5c41018a1c69152f16
Gitweb: http://git.kernel.org/tip/e03eaa400cf8b8bded86cc5c41018a1c69152f16
Author: David Ahern dsah...@gmail.com
AuthorDate: Tue, 24 Mar 2015 09:52:41 -0600
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Tue, 24 Mar
On 3/24/15 10:12 AM, Ingo Molnar wrote:
* David Ahern david.ah...@oracle.com wrote:
Record currently wakes up based on watermarks to read events from
the mmaps and write them out to the file. The result is a file that
can have large blocks of events per mmap before a finished round
event
, machine=0x4c9c88) at builtin-timechart.c:569
Another extended load on unaligned pointer. As before fix by copying to
a temporary variable using memcpy.
Signed-off-by: David Ahern david.ah...@oracle.com
---
tools/perf/util/evsel.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On 3/24/15 2:10 PM, Don Zickus wrote:
He does this with and without the patch. The difference is usually over 50%
extra time with the patch for both the record timings and report timings.:-(
I find that shocking. The patch only populates ppid and ptid with a
value read from the file that is
On 3/23/15 1:35 PM, David Miller wrote:
From: David Ahern
Date: Mon, 23 Mar 2015 11:34:34 -0600
seems like a formality at this point, but this resolves the panic on
the M7-based ldom and baremetal. The T5-8 failed to boot, but it could
be a different problem.
Specifically, does the T5-8
On 3/23/15 1:35 PM, David Miller wrote:
From: David Ahern
Date: Mon, 23 Mar 2015 11:34:34 -0600
seems like a formality at this point, but this resolves the panic on
the M7-based ldom and baremetal. The T5-8 failed to boot, but it could
be a different problem.
Specifically, does the T5-8
s good enough for how this thing is actually
used.
Reported-by: David Ahern
Reported-by: Bob Picco
Signed-off-by: David S. Miller
seems like a formality at this point, but this resolves the panic on the
M7-based ldom and baremetal. The T5-8 failed to boot, but it could be a
different prob
On 3/23/15 2:18 AM, Namhyung Kim wrote:
Just curious, could you try to measure the performance impact of this
change?
$ time perf record --call-graph dwarf -o kbuild.xxx -a -- sleep 30
[ perf record: Woken up 34674 times to write data ]
[ perf record: Captured and wrote 9538.729 MB
On 3/23/15 2:18 AM, Namhyung Kim wrote:
Just curious, could you try to measure the performance impact of this
change?
$ time perf record --call-graph dwarf -o kbuild.xxx -a -- sleep 30
[ perf record: Woken up 34674 times to write data ]
[ perf record: Captured and wrote 9538.729 MB
On 3/23/15 1:35 PM, David Miller wrote:
From: David Ahern david.ah...@oracle.com
Date: Mon, 23 Mar 2015 11:34:34 -0600
seems like a formality at this point, but this resolves the panic on
the M7-based ldom and baremetal. The T5-8 failed to boot, but it could
be a different problem
for how this thing is actually
used.
Reported-by: David Ahern david.ah...@oracle.com
Reported-by: Bob Picco bpi...@meloft.net
Signed-off-by: David S. Miller da...@davemloft.net
seems like a formality at this point, but this resolves the panic on the
M7-based ldom and baremetal. The T5-8 failed
On 3/23/15 1:35 PM, David Miller wrote:
From: David Ahern david.ah...@oracle.com
Date: Mon, 23 Mar 2015 11:34:34 -0600
seems like a formality at this point, but this resolves the panic on
the M7-based ldom and baremetal. The T5-8 failed to boot, but it could
be a different problem
On 3/22/15 5:54 PM, David Miller wrote:
I just put it on 4.0.0-rc4 and ditto -- problem goes away, so it
clearly suggests the memcpy or memmove are the root cause.
Thanks, didn't notice that.
So, something is amuck.
to continue to refine the problem ... I modified only the memmove lines
On 3/22/15 4:23 PM, David Miller wrote:
I don't even know which version of memcpy ends up being used on M7.
Some of them do things like use VIS. I can follow some regular sparc
asm, there's no way I'm even *looking* at that. Is it really ok to use
VIS registers in random contexts?
Yes, using
Commit-ID: 00ae1127a03d20f5ef89f3c1fe7d4720270fc2a5
Gitweb: http://git.kernel.org/tip/00ae1127a03d20f5ef89f3c1fe7d4720270fc2a5
Author: David Ahern
AuthorDate: Thu, 19 Mar 2015 12:36:21 -0600
Committer: Arnaldo Carvalho de Melo
CommitDate: Sat, 21 Mar 2015 14:53:38 -0300
tools lib
Commit-ID: 13f22a2d4a5359867aa05562fc922f1ca24873a5
Gitweb: http://git.kernel.org/tip/13f22a2d4a5359867aa05562fc922f1ca24873a5
Author: David Ahern
AuthorDate: Thu, 19 Mar 2015 12:23:03 -0600
Committer: Arnaldo Carvalho de Melo
CommitDate: Sat, 21 Mar 2015 14:53:31 -0300
perf trace
Commit-ID: 00ae1127a03d20f5ef89f3c1fe7d4720270fc2a5
Gitweb: http://git.kernel.org/tip/00ae1127a03d20f5ef89f3c1fe7d4720270fc2a5
Author: David Ahern dsah...@gmail.com
AuthorDate: Thu, 19 Mar 2015 12:36:21 -0600
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Sat, 21 Mar
Commit-ID: 13f22a2d4a5359867aa05562fc922f1ca24873a5
Gitweb: http://git.kernel.org/tip/13f22a2d4a5359867aa05562fc922f1ca24873a5
Author: David Ahern dsah...@gmail.com
AuthorDate: Thu, 19 Mar 2015 12:23:03 -0600
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Sat, 21 Mar
On 3/22/15 4:23 PM, David Miller wrote:
I don't even know which version of memcpy ends up being used on M7.
Some of them do things like use VIS. I can follow some regular sparc
asm, there's no way I'm even *looking* at that. Is it really ok to use
VIS registers in random contexts?
Yes, using
On 3/22/15 5:54 PM, David Miller wrote:
I just put it on 4.0.0-rc4 and ditto -- problem goes away, so it
clearly suggests the memcpy or memmove are the root cause.
Thanks, didn't notice that.
So, something is amuck.
to continue to refine the problem ... I modified only the memmove lines
On 3/20/15 6:47 PM, Linus Torvalds wrote:
Here's another data point: If I disable NUMA I don't see the problem.
Performance drops, but no NULL pointer splats which would have been panics.
So the NUMA case triggers the per-node "n->shared" logic, which
*should* be protected by "n->list_lock".
On 3/20/15 6:47 PM, Linus Torvalds wrote:
Here's another data point: If I disable NUMA I don't see the problem.
Performance drops, but no NULL pointer splats which would have been panics.
So the NUMA case triggers the per-node n-shared logic, which
*should* be protected by n-list_lock. Maybe
On 3/20/15 6:34 PM, David Rientjes wrote:
On Fri, 20 Mar 2015, David Ahern wrote:
Here's another data point: If I disable NUMA I don't see the problem.
Performance drops, but no NULL pointer splats which would have been panics.
The 128 cpu ldom with NUMA enabled shows the problem every single
On 3/20/15 4:49 PM, David Ahern wrote:
On 3/20/15 3:17 PM, Linus Torvalds wrote:
In other words, if I read that sparc asm right (and it is very likely
that I do *not*), then "objp" is NULL, and that's why you crash.
That does appear to be why. I put a WARN_ON before
clear_obj_
On 3/20/15 3:17 PM, Linus Torvalds wrote:
In other words, if I read that sparc asm right (and it is very likely
that I do *not*), then "objp" is NULL, and that's why you crash.
That does appear to be why. I put a WARN_ON before
clear_obj_pfmemalloc() if objpp[i] is NULL. I got 2 splats during
On 3/20/15 1:47 PM, David Miller wrote:
From: David Ahern
Date: Fri, 20 Mar 2015 12:05:05 -0600
DaveM: do you mind if I submit a patch to change the default for sparc
to SLUB?
I think we're jumping the gun about all of this, and doing anything
with default Kconfig settings would be entirely
On 3/20/15 12:53 PM, Linus Torvalds wrote:
SLUB should definitely be considered a stable allocator. It's the
default allocator for at least Fedora, and that presumably means all
of Redhat.
SuSE seems to use SLAB still, though, so it must be getting lots of
testing on x86 too.
Did you test
On 3/20/15 10:58 AM, Linus Torvalds wrote:
That said, SLAB is probably also almost unheard of in high-CPU
configurations, since slub has all the magical unlocked lists etc for
scalability. So maybe it's a generic SLAB bug, and nobody with lots of
CPU's is testing SLAB.
Evidently, it is a well
On 3/20/15 10:48 AM, Linus Torvalds wrote:
[ Added Davem and the sparc mailing list, since it happens on sparc
and that just makes me suspicious ]
On Fri, Mar 20, 2015 at 8:07 AM, David Ahern wrote:
I can easily reproduce the panic below doing a kernel build with make -j N,
N=128, 256, etc
On 3/20/15 10:26 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Mar 20, 2015 at 10:12:33AM -0600, David Ahern escreveu:
On 3/20/15 10:06 AM, Arnaldo Carvalho de Melo wrote:
- for (field = sc->tp_format->format.fields->next; field;
+ for (field = sc->
On 3/20/15 10:06 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Mar 20, 2015 at 09:48:10AM -0600, David Ahern escreveu:
On 3/20/15 9:32 AM, Arnaldo Carvalho de Melo wrote:
But then I don't think we need to do that, i.e. we can just have a
boolean we set at some point to tell that we need to skip
On 3/20/15 9:44 AM, Arnaldo Carvalho de Melo wrote:
Ok, so I'll put it in a separate patch, authored by David, with your
Acked-by, it may be useful at some point besides being used in the
libtraceevent internal free_format_fields() static function.
Works for me. Thanks, Arnaldo.
--
To
On 3/20/15 9:32 AM, Arnaldo Carvalho de Melo wrote:
But then I don't think we need to do that, i.e. we can just have a
boolean we set at some point to tell that we need to skip the first
entry.
I'll try to cook up a patch for that.
why have a boolean that is checked every time through the
I can easily reproduce the panic below doing a kernel build with make -j
N, N=128, 256, etc. This is a 1024 cpu system running 4.0.0-rc4.
The top 3 frames are consistently:
free_block+0x60
cache_flusharray+0xac
kmem_cache_free+0xfc
After that one path has been from __mmdrop and the
On 3/20/15 6:34 PM, David Rientjes wrote:
On Fri, 20 Mar 2015, David Ahern wrote:
Here's another data point: If I disable NUMA I don't see the problem.
Performance drops, but no NULL pointer splats which would have been panics.
The 128 cpu ldom with NUMA enabled shows the problem every single
On 3/20/15 4:49 PM, David Ahern wrote:
On 3/20/15 3:17 PM, Linus Torvalds wrote:
In other words, if I read that sparc asm right (and it is very likely
that I do *not*), then objp is NULL, and that's why you crash.
That does appear to be why. I put a WARN_ON before
clear_obj_pfmemalloc
I can easily reproduce the panic below doing a kernel build with make -j
N, N=128, 256, etc. This is a 1024 cpu system running 4.0.0-rc4.
The top 3 frames are consistently:
free_block+0x60
cache_flusharray+0xac
kmem_cache_free+0xfc
After that one path has been from __mmdrop and the
On 3/20/15 9:44 AM, Arnaldo Carvalho de Melo wrote:
Ok, so I'll put it in a separate patch, authored by David, with your
Acked-by, it may be useful at some point besides being used in the
libtraceevent internal free_format_fields() static function.
Works for me. Thanks, Arnaldo.
--
To
On 3/20/15 9:32 AM, Arnaldo Carvalho de Melo wrote:
But then I don't think we need to do that, i.e. we can just have a
boolean we set at some point to tell that we need to skip the first
entry.
I'll try to cook up a patch for that.
why have a boolean that is checked every time through the
On 3/20/15 12:53 PM, Linus Torvalds wrote:
SLUB should definitely be considered a stable allocator. It's the
default allocator for at least Fedora, and that presumably means all
of Redhat.
SuSE seems to use SLAB still, though, so it must be getting lots of
testing on x86 too.
Did you test
On 3/20/15 10:58 AM, Linus Torvalds wrote:
That said, SLAB is probably also almost unheard of in high-CPU
configurations, since slub has all the magical unlocked lists etc for
scalability. So maybe it's a generic SLAB bug, and nobody with lots of
CPU's is testing SLAB.
Evidently, it is a well
On 3/20/15 10:06 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Mar 20, 2015 at 09:48:10AM -0600, David Ahern escreveu:
On 3/20/15 9:32 AM, Arnaldo Carvalho de Melo wrote:
But then I don't think we need to do that, i.e. we can just have a
boolean we set at some point to tell that we need to skip
On 3/20/15 10:48 AM, Linus Torvalds wrote:
[ Added Davem and the sparc mailing list, since it happens on sparc
and that just makes me suspicious ]
On Fri, Mar 20, 2015 at 8:07 AM, David Ahern david.ah...@oracle.com wrote:
I can easily reproduce the panic below doing a kernel build with make -j
On 3/20/15 10:26 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Mar 20, 2015 at 10:12:33AM -0600, David Ahern escreveu:
On 3/20/15 10:06 AM, Arnaldo Carvalho de Melo wrote:
- for (field = sc-tp_format-format.fields-next; field;
+ for (field = sc-args; field
On 3/20/15 1:47 PM, David Miller wrote:
From: David Ahern david.ah...@oracle.com
Date: Fri, 20 Mar 2015 12:05:05 -0600
DaveM: do you mind if I submit a patch to change the default for sparc
to SLUB?
I think we're jumping the gun about all of this, and doing anything
with default Kconfig
On 3/20/15 3:17 PM, Linus Torvalds wrote:
In other words, if I read that sparc asm right (and it is very likely
that I do *not*), then objp is NULL, and that's why you crash.
That does appear to be why. I put a WARN_ON before
clear_obj_pfmemalloc() if objpp[i] is NULL. I got 2 splats during
On 3/19/15 2:56 PM, Don Zickus wrote:
On Thu, Mar 19, 2015 at 11:41:15AM -0600, David Ahern wrote:
>363b785f38 added synthesized fork events and set a thread's parent id
>to itself. Since we are already processing/proc//status the ppid
>can be determined properly. Make it so.
Thanks D
( 0.003 ms): dd/6330 write(fd: 2, buf: 0x7fff22fc81f0,
count: 25 ) = 25
Signed-off-by: David Ahern
---
tools/lib/traceevent/event-parse.c | 11 ---
tools/lib/traceevent/event-parse.h | 1 +
tools/perf/builtin-trace.c | 16 +---
3 files changed, 22
for the summary only option.
Signed-off-by: David Ahern
---
tools/perf/builtin-trace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 6969ba98ff2f..dcd950ef2fd7 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools
363b785f38 added synthesized fork events and set a thread's parent id
to itself. Since we are already processing /proc//status the ppid
can be determined properly. Make it so.
Signed-off-by: David Ahern
Cc: Don Zickus
Cc: Jiri Olsa
---
tools/perf/util/event.c | 94
On 3/19/15 7:20 AM, Don Zickus wrote:
Honestly I don't recall. The commit log tells you the problem I was trying
to solve. Instead of parsing text strings from/proc/maps/, I believe
it was wy faster to copy the thread maps.
This could have been an oversight. I might have falsely assumed
On 3/19/15 7:20 AM, Don Zickus wrote:
Honestly I don't recall. The commit log tells you the problem I was trying
to solve. Instead of parsing text strings from/proc/maps/pid, I believe
it was wy faster to copy the thread maps.
This could have been an oversight. I might have falsely
for the summary only option.
Signed-off-by: David Ahern dsah...@gmail.com
---
tools/perf/builtin-trace.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 6969ba98ff2f..dcd950ef2fd7 100644
--- a/tools/perf/builtin
363b785f38 added synthesized fork events and set a thread's parent id
to itself. Since we are already processing /proc/pid/status the ppid
can be determined properly. Make it so.
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Jiri Olsa jo...@redhat.com
:
1.813 ( 0.003 ms): dd/6330 write(fd: 2/dev/pts/0, buf: 0x7fff22fc81f0,
count: 25 ) = 25
Signed-off-by: David Ahern dsah...@gmail.com
---
tools/lib/traceevent/event-parse.c | 11 ---
tools/lib/traceevent/event-parse.h | 1 +
tools/perf/builtin-trace.c | 16
On 3/19/15 2:56 PM, Don Zickus wrote:
On Thu, Mar 19, 2015 at 11:41:15AM -0600, David Ahern wrote:
363b785f38 added synthesized fork events and set a thread's parent id
to itself. Since we are already processing/proc/pid/status the ppid
can be determined properly. Make it so.
Thanks David. My
Don:
In this commit:
commit 363b785f3805a2632eb09a8b430842461c21a640
Author: Don Zickus
Date: Fri Mar 14 10:43:44 2014 -0400
perf tools: Speed up thread map generation
you made a thread its own parent when synthesizing fork events:
static int perf_event__synthesize_fork(struct
On 3/18/15 2:14 PM, David Miller wrote:
Oh I see, you're using older sources which don't have:
commit abaf3787ac26ba33e2f75e76b1174c32254c25b0
Author: Paul Gortmaker
Date: Thu Jan 23 15:55:45 2014 -0800
fs/proc: don't use module_init for non-modular core
On 3/18/15 1:43 PM, David Miller wrote:
From: David Ahern
Date: Wed, 18 Mar 2015 10:56:22 -0600
I am trying to understand why the perf tool on sparc fails to convert
kernel symbols when /proc/kcore is used. I have instrumented perf to
the point I can see that it drops symbols from kallsyms
I am trying to understand why the perf tool on sparc fails to convert
kernel symbols when /proc/kcore is used. I have instrumented perf to the
point I can see that it drops symbols from kallsyms because it cannot
find a corresponding map when the kernel maps are created based on
parsing
I am trying to understand why the perf tool on sparc fails to convert
kernel symbols when /proc/kcore is used. I have instrumented perf to the
point I can see that it drops symbols from kallsyms because it cannot
find a corresponding map when the kernel maps are created based on
parsing
Don:
In this commit:
commit 363b785f3805a2632eb09a8b430842461c21a640
Author: Don Zickus dzic...@redhat.com
Date: Fri Mar 14 10:43:44 2014 -0400
perf tools: Speed up thread map generation
you made a thread its own parent when synthesizing fork events:
static int
On 3/18/15 1:43 PM, David Miller wrote:
From: David Ahern david.ah...@oracle.com
Date: Wed, 18 Mar 2015 10:56:22 -0600
I am trying to understand why the perf tool on sparc fails to convert
kernel symbols when /proc/kcore is used. I have instrumented perf to
the point I can see that it drops
On 3/18/15 2:14 PM, David Miller wrote:
Oh I see, you're using older sources which don't have:
commit abaf3787ac26ba33e2f75e76b1174c32254c25b0
Author: Paul Gortmaker paul.gortma...@windriver.com
Date: Thu Jan 23 15:55:45 2014 -0800
fs/proc: don't use
Commit-ID: 6d4a48968bfb5c67002f253fbaeb5acd41d7897a
Gitweb: http://git.kernel.org/tip/6d4a48968bfb5c67002f253fbaeb5acd41d7897a
Author: David Ahern
AuthorDate: Wed, 11 Mar 2015 10:36:20 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 12 Mar 2015 12:40:00 -0300
perf probe
1001 - 1100 of 3566 matches
Mail list logo
