[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20080624123715.15bd3cb5.kamezawa.hiroyu@jp.fujitsu.com>
Date: Tue, 24 Jun 2008 12:37:15 +0900
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To: Randy Dunlap <randy.dunlap@...cle.com>
Cc: "linux-mm@...ck.org" <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
"menage@...gle.com" <menage@...gle.com>,
"balbir@...ux.vnet.ibm.com" <balbir@...ux.vnet.ibm.com>,
"xemul@...nvz.org" <xemul@...nvz.org>,
"yamamoto@...inux.co.jp" <yamamoto@...inux.co.jp>,
"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>,
"lizf@...fujitsu.com" <lizf@...fujitsu.com>
Subject: Re: [PATCH 6/6] memcg: HARDWALL hierarchy
On Mon, 23 Jun 2008 15:29:41 -0700
Randy Dunlap <randy.dunlap@...cle.com> wrote:
> On Fri, 13 Jun 2008 18:37:41 +0900 KAMEZAWA Hiroyuki wrote:
>
> > Support hardwall hierarchy (and no-hierarchy) in memcg.
> >
> > Change log: v3->v4
> > - cut out from memcg hierarchy patch set v4.
> > - no major changes, but some amount of functions are moved to res_counter.
> > and be more gneric.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
> >
> > ---
> > Documentation/controllers/memory.txt | 57 +++++++++++++++++++++++++++++-
> > mm/memcontrol.c | 65 +++++++++++++++++++++++++++++++++--
> > 2 files changed, 118 insertions(+), 4 deletions(-)
> >
> > Index: linux-2.6.26-rc5-mm3/Documentation/controllers/memory.txt
> > ===================================================================
> > --- linux-2.6.26-rc5-mm3.orig/Documentation/controllers/memory.txt
> > +++ linux-2.6.26-rc5-mm3/Documentation/controllers/memory.txt
> > @@ -154,7 +154,7 @@ The memory controller uses the following
> >
> > 0. Configuration
>
> I apologize if you have already corrected these. I'm a bit behind
> on doc reviews.
>
Thank you for all your help. I'll check my set again especially
's' and 'a/an'.
>
> > -a. Enable CONFIG_CGROUPS
> > +a. Enable CONFESS_CGROUPS
>
> Really? Looks odd and backwards.
>
my mistake..
Thanks,
-Kame
> > b. Enable CONFIG_RESOURCE_COUNTERS
> > c. Enable CONFIG_CGROUP_MEM_RES_CTLR
> >
> > @@ -237,7 +237,58 @@ cgroup might have some charge associated
> > tasks have migrated away from it. Such charges are automatically dropped at
> > rmdir() if there are no tasks.
> >
> > -5. TODO
> > +5. Supported Hierarchy Model
> > +
> > +Currently, memory controller supports following models of hierarchy in the
> > +kernel. (see also resource_counter.txt)
> > +
> > +2 files are related to hierarchy.
> > + - memory.hierarchy_model
> > + - memory.for_children
> > +
> > +Basic Rule.
> > + - Hierarchy can be set per cgroup.
> > + - A child inherits parent's hierarchy model at creation.
> > + - A child can change its hierarchy only when the parent's hierarchy is
> > + NO_HIERARCY and it has no children.
>
> NO_HIERARCHY
>
sure
> > +
> > +
> > +5.1. NO_HIERARCHY
> > + - Each cgroup is independent from other ones.
> > + - When memory.hierarchy_model is 0, NO_HIERARCHY is used.
> > + Under this model, there is no controls based on tree of cgroups.
>
> there are no controls
>
Oh, thanks.
> > + This is the default model of root cgroup.
> > +
> > +5.2 HARDWALL_HIERARCHY
> > + - A child is a isolated portion of the parent.
>
> is an
>
> > + - When memory.hierarchy_model is 1, HARDWALL_HIERARCHY is used.
> > + In this model a child's limit is charged as parent's usage.
> > +
> > + Hard-Wall Hierarchy Example)
>
> Drop ')'.
>
> > + 1) Assume a cgroup with 1GB limits. (and no tasks belongs to this, now)
> > + - group_A limit=1G,usage=0M.
>
> , usage=0M.
>
> > +
> > + 2) create group B, C under A.
> > + - group A limit=1G, usage=0M, for_childre=0M
>
> for_children=0M
>
> > + - group B limit=0M, usage=0M.
> > + - group C limit=0M, usage=0M.
> > +
> > + 3) increase group B's limit to 300M.
> > + - group A limit=1G, usage=300M, for_children=300M
> > + - group B limit=300M, usage=0M.
> > + - group C limit=0M, usage=0M.
> > +
> > + 4) increase group C's limit to 500M
> > + - group A limit=1G, usage=800M, for_children=800M
> > + - group B limit=300M, usage=0M.
> > + - group C limit=500M, usage=0M.
> > +
> > + 5) reduce group B's limit to 100M
> > + - group A limit=1G, usage=600M, for_children=600M.
> > + - group B limit=100M, usage=0M.
> > + - group C limit=500M, usage=0M.
>
>
> ---
> ~Randy
> Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
> http://linuxplumbersconf.org/
>
--
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