All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	Andrew Morton <akpm@linux-foundation.org>,
	"lizf@cn.fujitsu.com" <lizf@cn.fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"menage@google.com" <menage@google.com>,
	xemul@openvz.org, prarit@redhat.com, andi.kleen@intel.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [UPDATED][PATCH][mmotm] Help Root Memory Cgroup Resource Counters Scale Better (v5)
Date: Thu, 13 Aug 2009 14:13:16 +0530	[thread overview]
Message-ID: <20090813084316.GI5087@balbir.in.ibm.com> (raw)
In-Reply-To: <20090813083524.GC21389@elte.hu>

* Ingo Molnar <mingo@elte.hu> [2009-08-13 10:35:24]:

> 
> * Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > Without Patch
> > 
> >  Performance counter stats for '/home/balbir/parallel_pagefault':
> > 
> >   5826093739340  cycles                   #    809.989 M/sec
> >    408883496292  instructions             #      0.070 IPC
> >      7057079452  cache-references         #      0.981 M/sec
> >      3036086243  cache-misses             #      0.422 M/sec
> 
> > With this patch applied
> > 
> >  Performance counter stats for '/home/balbir/parallel_pagefault':
> > 
> >   5957054385619  cycles                   #    828.333 M/sec
> >   1058117350365  instructions             #      0.178 IPC
> >      9161776218  cache-references         #      1.274 M/sec
> >      1920494280  cache-misses             #      0.267 M/sec
> 
> Nice how the instruction count and the IPC value incraesed, and the 
> cache-miss count decreased.
> 
> Btw., a 'perf stat' suggestion: you can also make use of built-in 
> error bars via repeating parallel_pagefault N times:
> 
>   aldebaran:~> perf stat --repeat 3 /bin/ls
> 
>  Performance counter stats for '/bin/ls' (3 runs):
> 
>        1.108886  task-clock-msecs         #      0.875 CPUs    ( +-   4.316% )
>               0  context-switches         #      0.000 M/sec   ( +-   0.000% )
>               0  CPU-migrations           #      0.000 M/sec   ( +-   0.000% )
>             254  page-faults              #      0.229 M/sec   ( +-   0.000% )
>         3461896  cycles                   #   3121.958 M/sec   ( +-   3.508% )
>         3044445  instructions             #      0.879 IPC     ( +-   0.134% )
>           21213  cache-references         #     19.130 M/sec   ( +-   1.612% )
>            2610  cache-misses             #      2.354 M/sec   ( +-  39.640% )
> 
>     0.001267355  seconds time elapsed   ( +-   4.762% )
> 
> that way even small changes in metrics can be identified as positive 
> effects of a patch, if the improvement is beyond the error 
> percentage that perf reports.
> 
> For example in the /bin/ls numbers i cited above, the 'instructions' 
> value can be trusted up to 99.8% (with a ~0.13% noise), while say 
> the cache-misses value can not really be trusted, as it has 40% of 
> noise. (Increasing the repeat count will drive down the noise level 
> - at the cost of longer measurement time.)
> 
> For your patch the improvement is so drastic that this isnt needed - 
> but the error estimations can be quite useful for more borderline 
> improvements. (and they are also useful in finding and proving small 
> performance regressions)

Thanks for the tip, let me try and use the repeats feature. BTW, nice
work on the perf counters, I was pleasantly surprised to see a
wonderful tool in the kernel with a good set of options and detailed
analysis capabilities.

-- 
	Balbir

WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	Andrew Morton <akpm@linux-foundation.org>,
	"lizf@cn.fujitsu.com" <lizf@cn.fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"menage@google.com" <menage@google.com>,
	xemul@openvz.org, prarit@redhat.com, andi.kleen@intel.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [UPDATED][PATCH][mmotm] Help Root Memory Cgroup Resource Counters Scale Better (v5)
Date: Thu, 13 Aug 2009 14:13:16 +0530	[thread overview]
Message-ID: <20090813084316.GI5087@balbir.in.ibm.com> (raw)
In-Reply-To: <20090813083524.GC21389@elte.hu>

* Ingo Molnar <mingo@elte.hu> [2009-08-13 10:35:24]:

> 
> * Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > Without Patch
> > 
> >  Performance counter stats for '/home/balbir/parallel_pagefault':
> > 
> >   5826093739340  cycles                   #    809.989 M/sec
> >    408883496292  instructions             #      0.070 IPC
> >      7057079452  cache-references         #      0.981 M/sec
> >      3036086243  cache-misses             #      0.422 M/sec
> 
> > With this patch applied
> > 
> >  Performance counter stats for '/home/balbir/parallel_pagefault':
> > 
> >   5957054385619  cycles                   #    828.333 M/sec
> >   1058117350365  instructions             #      0.178 IPC
> >      9161776218  cache-references         #      1.274 M/sec
> >      1920494280  cache-misses             #      0.267 M/sec
> 
> Nice how the instruction count and the IPC value incraesed, and the 
> cache-miss count decreased.
> 
> Btw., a 'perf stat' suggestion: you can also make use of built-in 
> error bars via repeating parallel_pagefault N times:
> 
>   aldebaran:~> perf stat --repeat 3 /bin/ls
> 
>  Performance counter stats for '/bin/ls' (3 runs):
> 
>        1.108886  task-clock-msecs         #      0.875 CPUs    ( +-   4.316% )
>               0  context-switches         #      0.000 M/sec   ( +-   0.000% )
>               0  CPU-migrations           #      0.000 M/sec   ( +-   0.000% )
>             254  page-faults              #      0.229 M/sec   ( +-   0.000% )
>         3461896  cycles                   #   3121.958 M/sec   ( +-   3.508% )
>         3044445  instructions             #      0.879 IPC     ( +-   0.134% )
>           21213  cache-references         #     19.130 M/sec   ( +-   1.612% )
>            2610  cache-misses             #      2.354 M/sec   ( +-  39.640% )
> 
>     0.001267355  seconds time elapsed   ( +-   4.762% )
> 
> that way even small changes in metrics can be identified as positive 
> effects of a patch, if the improvement is beyond the error 
> percentage that perf reports.
> 
> For example in the /bin/ls numbers i cited above, the 'instructions' 
> value can be trusted up to 99.8% (with a ~0.13% noise), while say 
> the cache-misses value can not really be trusted, as it has 40% of 
> noise. (Increasing the repeat count will drive down the noise level 
> - at the cost of longer measurement time.)
> 
> For your patch the improvement is so drastic that this isnt needed - 
> but the error estimations can be quite useful for more borderline 
> improvements. (and they are also useful in finding and proving small 
> performance regressions)

Thanks for the tip, let me try and use the repeats feature. BTW, nice
work on the perf counters, I was pleasantly surprised to see a
wonderful tool in the kernel with a good set of options and detailed
analysis capabilities.

-- 
	Balbir

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-08-13  8:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-13  6:55 [PATCH][mmotm] Help Root Memory Cgroup Resource Counters Scale Better (v5) Balbir Singh
2009-08-13  6:55 ` Balbir Singh
2009-08-13  7:26 ` Daisuke Nishimura
2009-08-13  7:26   ` Daisuke Nishimura
2009-08-13  8:02   ` [UPDATED][PATCH][mmotm] " Balbir Singh
2009-08-13  8:02     ` Balbir Singh
2009-08-13  8:35     ` Ingo Molnar
2009-08-13  8:35       ` Ingo Molnar
2009-08-13  8:43       ` Balbir Singh [this message]
2009-08-13  8:43         ` Balbir Singh
2009-08-14  2:01       ` Balbir Singh
2009-08-14  2:01         ` Balbir Singh
2009-08-15 14:26         ` Ingo Molnar
2009-08-15 14:26           ` Ingo Molnar
2009-08-13 11:12     ` Daisuke Nishimura
2009-08-13 11:12       ` Daisuke Nishimura

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090813084316.GI5087@balbir.in.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi.kleen@intel.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=menage@google.com \
    --cc=mingo@elte.hu \
    --cc=nishimura@mxp.nes.nec.co.jp \
    --cc=prarit@redhat.com \
    --cc=xemul@openvz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.