From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Ying Han <yinghan@google.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>
Subject: Re: [PATCH 0/2] memcg: improving scalability by reducing lock contention at charge/uncharge
Date: Tue, 13 Oct 2009 10:28:27 +0900 [thread overview]
Message-ID: <20091013102827.c0280e37.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <604427e00910121818w71dd4b7dl8781d7f5bc4f7dd9@mail.gmail.com>
On Mon, 12 Oct 2009 18:18:44 -0700
Ying Han <yinghan@google.com> wrote:
> Ok. After I am running the task in the child cgroup, I do see performance
> improvement on the page-faults .
Thank you.
Hmm...I wonder what makes cache-miss dramatically larger.
4 process on 4 cpus ? (my script was for 8cpus.)
-Kame
> [Before]
> Performance counter stats for './runpause.sh 10' (5 runs):
>
> 226190.612998 task-clock-msecs # 3.766 CPUs ( +- 0.192%
> )
> 4454 context-switches # 0.000 M/sec ( +- 14.029%
> )
> 38 CPU-migrations # 0.000 M/sec ( +- 15.385%
> )
> 21445296 page-faults # 0.095 M/sec ( +- 1.686%
> )
> 498345012124 cycles # 2203.208 M/sec ( +- 0.023%
> )
> 255638483632 instructions # 0.513 IPC ( +- 0.196%
> )
> 92240143452 cache-references # 407.798 M/sec ( +- 0.673%
> )
> 175412792 cache-misses # 0.776 M/sec ( +- 2.188%
> )
>
> 60.068670564 seconds time elapsed ( +- 0.014% )
>
> [After]
> Performance counter stats for './runpause.sh 10' (5 runs):
>
> 214409.926571 task-clock-msecs # 3.570 CPUs ( +- 0.317%
> )
> 3097 context-switches # 0.000 M/sec ( +- 25.726%
> )
> 14 CPU-migrations # 0.000 M/sec ( +- 20.000%
> )
> 33977467 page-faults # 0.158 M/sec ( +- 4.884%
> )
> 472369769787 cycles # 2203.115 M/sec ( +- 0.024%
> )
> 275624185415 instructions # 0.583 IPC ( +- 0.271%
> )
> 98359325470 cache-references # 458.744 M/sec ( +- 0.281%
> )
> 941121561 cache-misses # 4.389 M/sec ( +- 4.969%
> )
>
> 60.052748032 seconds time elapsed ( +- 0.013% )
>
> --Ying
>
>
> On Mon, Oct 12, 2009 at 5:29 PM, KAMEZAWA Hiroyuki <
> kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > On Sun, 11 Oct 2009 11:34:39 -0700
> > Ying Han <yinghan@google.com> wrote:
> >
> > > 2009/10/10 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> >
> > > > This patch series is only for "child" cgroup. Sorry, I had to write it
> > > > clearer. No effects to root.
> > > >
> > >
> > > Ok, Thanks for making it clearer. :) So Do you mind post the cgroup+memcg
> > > configuration
> > > while you are running on your host?
> > >
> >
> > #mount -t cgroup /dev/null /cgroups -omemory
> > #mkdir /cgroups/A
> > #echo $$ > /cgroups/A
> >
> > and run test.
> >
> > Thanks,
> > -Kame
> >
> >
> >
>
--
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>
prev parent reply other threads:[~2009-10-13 1:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-02 4:55 KAMEZAWA Hiroyuki
2009-10-02 5:01 ` [PATCH 1/2] memcg: coalescing uncharge at unmap and truncation KAMEZAWA Hiroyuki
2009-10-02 6:47 ` Hiroshi Shimamoto
2009-10-02 6:53 ` Hiroshi Shimamoto
2009-10-02 7:04 ` KAMEZAWA Hiroyuki
2009-10-02 7:02 ` [PATCH 1/2] memcg: coalescing uncharge at unmap and truncation (fixed coimpile bug) KAMEZAWA Hiroyuki
2009-10-08 22:17 ` Andrew Morton
2009-10-08 23:48 ` KAMEZAWA Hiroyuki
2009-10-09 4:01 ` [PATCH 1/2] memcg: coalescing uncharge at unmap and truncation Balbir Singh
2009-10-09 4:17 ` KAMEZAWA Hiroyuki
2009-10-02 5:03 ` [PATCH 2/2] memcg: coalescing charges per cpu KAMEZAWA Hiroyuki
2009-10-08 22:26 ` Andrew Morton
2009-10-08 23:54 ` KAMEZAWA Hiroyuki
2009-10-09 4:15 ` Balbir Singh
2009-10-09 4:25 ` KAMEZAWA Hiroyuki
2009-10-02 8:53 ` [PATCH 0/2] memcg: improving scalability by reducing lock contention at charge/uncharge KAMEZAWA Hiroyuki
2009-10-05 7:18 ` KAMEZAWA Hiroyuki
2009-10-05 10:37 ` Balbir Singh
[not found] ` <604427e00910091737s52e11ce9p256c95d533dc2837@mail.gmail.com>
2009-10-11 2:33 ` KAMEZAWA Hiroyuki
[not found] ` <604427e00910111134o6f22f0ddg2b87124dd334ec02@mail.gmail.com>
2009-10-12 11:38 ` Balbir Singh
2009-10-13 0:29 ` KAMEZAWA Hiroyuki
[not found] ` <604427e00910121818w71dd4b7dl8781d7f5bc4f7dd9@mail.gmail.com>
2009-10-13 1:28 ` KAMEZAWA Hiroyuki [this message]
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=20091013102827.c0280e37.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nishimura@mxp.nes.nec.co.jp \
--cc=yinghan@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox