On Fri, Mar 27, 2015 at 02:10:54PM -0600, David Ahern wrote:
> On 3/27/15 1:49 PM, Don Zickus wrote:
> >diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> >index 1c8fbc9..7ee3823 100644
> >--- a/tools/perf/util/thread.c
> >+++ b/tools/perf/util/thread.c
> >@@ -187,6 +187,7 @@ static
On 3/27/15 1:49 PM, Don Zickus wrote:
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 1c8fbc9..7ee3823 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -187,6 +187,7 @@ static int thread__clone_map_groups(struct thread *thread,
if (thread->pid
Em Fri, Mar 27, 2015 at 03:49:41PM -0400, Don Zickus escreveu:
> On Fri, Mar 27, 2015 at 11:20:36AM -0300, Arnaldo Carvalho de Melo wrote:
> > ... which is what David is suggesting here:
> >
> > > Try this:
> > > perf record -o unpatched.data -g -- perf.unpatched mem record -a -e
> > > cpu/mem-lo
On Fri, Mar 27, 2015 at 11:20:36AM -0300, Arnaldo Carvalho de Melo wrote:
> ... which is what David is suggesting here:
>
> > Try this:
> > perf record -o unpatched.data -g -- perf.unpatched mem record -a -e
> > cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10
> >
> > perf record -o patch
Em Fri, Mar 27, 2015 at 08:03:28AM -0600, David Ahern escreveu:
> On 3/27/15 7:10 AM, Don Zickus wrote:
> >I talked with Joe on my way out the door yesterday and he confirmed, just
> >removing -BN from our test showed a performance hit with your patch. With
> >the -BN option, there is no performan
On 3/27/15 7:10 AM, Don Zickus wrote:
I talked with Joe on my way out the door yesterday and he confirmed, just
removing -BN from our test showed a performance hit with your patch. With
the -BN option, there is no performance hit and we are perfectly fine with
your patch.
So, I guess I am confu
On Thu, Mar 26, 2015 at 03:37:29PM -0600, David Ahern wrote:
> On 3/26/15 3:11 PM, Don Zickus wrote:
> >Sorry for drawing this out. Originally the performance still seemed off.
> >But as we split the patch up to see where the perf impact was, the problem
> >seemed to have disappeared. So we are t
On 3/26/15 3:11 PM, Don Zickus wrote:
Sorry for drawing this out. Originally the performance still seemed off.
But as we split the patch up to see where the perf impact was, the problem
seemed to have disappeared. So we are testing the original patch again.
The only difference now is we were p
On Wed, Mar 25, 2015 at 01:55:44PM -0600, David Ahern wrote:
> >Hmm, I am not entirely sure this is correct. You made an optimization that
> >hides the negative impact your patch does. I would prefer you split this
> >patch into two pieces. One with the read loop optimization (which I think
> >i
On Wed, Mar 25, 2015 at 01:55:44PM -0600, David Ahern wrote:
> 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//status
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//status the ppid
can be determined properly. Make it so.
Performance impact m
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//status the ppid
> can be determined properly. Make it so.
>
> Performance impact measured on a sparc based T5-8 (
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.
Performance impact measured on a sparc based T5-8 (1024 CPUs):
$ ps -efL | wc -l
20185
Current code:
$ time perf record -
13 matches
Mail list logo
