[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080910200304.fd078007.kamezawa.hiroyu@jp.fujitsu.com>
Date: Wed, 10 Sep 2008 20:03:04 +0900
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: balbir@...ux.vnet.ibm.com,
Andrew Morton <akpm@...ux-foundation.org>, hugh@...itas.com,
menage@...gle.com, xemul@...nvz.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [Approach #2] [RFC][PATCH] Remove cgroup member from struct
page
On Thu, 11 Sep 2008 06:44:37 +1000
Nick Piggin <nickpiggin@...oo.com.au> wrote:
> On Wednesday 10 September 2008 11:49, KAMEZAWA Hiroyuki wrote:
> > On Tue, 9 Sep 2008 18:20:48 -0700
> >
> > Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
> > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> [2008-09-09
> > > 21:30:12]: OK, here is approach #2, it works for me and gives me really
> > > good performance (surpassing even the current memory controller). I am
> > > seeing almost a 7% increase
> >
> > This number is from pre-allcation, maybe.
> > We really do alloc-at-boot all page_cgroup ? This seems a big change.
>
> It seems really nice to me -- we get the best of both worlds, less overhead
> for those who don't enable the memory controller, and even better
> performance for those who do.
No trobles for me for allocating-all-at-boot policy.
My small concern is
- wasting page_cgroup for hugepage area.
- memory hotplug
>
> Are you expecting many users to want to turn this on and off at runtime?
> I wouldn't expect so, but I don't know enough about them.
>
There is no runtime switch. only at boot.
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists