[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100104000752.GC16187@balbir.in.ibm.com>
Date: Mon, 4 Jan 2010 05:37:52 +0530
From: Balbir Singh <balbir@...ux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc: "linux-mm@...ck.org" <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>
Subject: Re: [RFC] Shared page accounting for memory cgroup
* KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> [2010-01-04 08:51:08]:
> On Tue, 29 Dec 2009 23:57:43 +0530
> Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
>
> > Hi, Everyone,
> >
> > I've been working on heuristics for shared page accounting for the
> > memory cgroup. I've tested the patches by creating multiple cgroups
> > and running programs that share memory and observed the output.
> >
> > Comments?
>
> Hmm? Why we have to do this in the kernel ?
>
For several reasons that I can think of
1. With task migration changes coming in, getting consistent data free of races
is going to be hard.
2. The cost of doing it in the kernel is not high, it does not impact
the memcg runtime, it is a request-response sort of cost.
3. The cost in user space is going to be high and the implementation
cumbersome to get right.
--
Balbir
--
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