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>
next prev parent 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.