Date:	Mon, 29 Sep 2008 12:27:51 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	balbir@...ux.vnet.ibm.com
Cc:	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>,
	"xemul@...nvz.org" <xemul@...nvz.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Dave Hansen <haveblue@...ibm.com>, ryov@...inux.co.jp,
	YAMAMOTO Takashi <yamamoto@...inux.co.jp>
Subject: Re: [PATCH 0/12] memcg updates v5

On Mon, 29 Sep 2008 08:32:07 +0530
Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:

> KAMEZAWA Hiroyuki wrote:
> > On Fri, 26 Sep 2008 19:36:02 +0900
> > KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> wrote:
> > 
> >>> I think (1) might be OK, except for the accounting issues pointed out (change in
> >>> behaviour visible to end user again, sigh! :( ).
> >> But it was just a BUG from my point of view...
> >>
> >>> Is (1) a serious issue? 
> >> considering force_empty(), it's serious.
> >>
> >>> (2) seems OK, except for the locking change for mark_page_accessed. I am looking at
> >>> (4) and (6) currently.
> >>>
> > 
> > I'll do in following way in the next Monday.
> > Divide patches into 2 set
> > 
> > in early fix/optimize set.
> >   - push (2)
> >   - push (4)
> >   - push (6)
> >   - push (1)
> > 
> 
> Yes, sounds reasonable
> 
I'll just post this, today. 

> > drops (3).
> > 
> > I don't want to remove all? pages-never-on-LRU before fixing force_empty.
> > 
> > in updates
> >   - introduce atomic flags. (5)
> >   - add move_account() function (7)
> 
> without (3), don't we have a problem pushing (7)?
> 
I'll add -EBUSY behavior to force_empty.
I'm now adding(merging) code to move_account.patch for supporing force_empty.
It seems much clearer than v5.


> >   - add memory.attribute to each memcg dir. (NEW)
> >   - enhance force_empty (was (8))
> >        - remove "forget all" logic. and add attribute to select following 2 behavior
> >           - call try_to_free_page() until the usage goes down to 0.
> >             This allows faiulre (if page is mlocked, we can't do.). (NEW)
> >           - call move_account() to move all charges to its parent (as much as possible) (NEW)
> >           In future, I'd liket to add trash-box cgroup for force_empty somewhere.
> >   - allocate all page cgroup at boot (9)
> >   - lazy lru free/add (10,11) with fixes.
> >   - fix race at charging swap. (12)
> > 
> 
> I think (9) is probably the most important. I'll review it today
> 
Thanks. no major changes in my current stack from already posted one.

Thanks,
-Kame

> > After (9), all page and page_cgroup has one-to-one releationship and we want to
> > assume that "if page is alive and on LRU, it's accounted and has page_cgroup."
> > (other team, bio cgroup want to use page_cgroup and I want to make it easy.)
> > 
> > For this, fix to behavior of force_empty..."forget all" is necessary.
> > SwapCache handling is also necessary but I'd like to postpone until next set
> > because it's complicated.
> > 
> > After above all.
> >  - handle swap cache 
> >  - Mem+Swap controller.
> >  - add trashbox feature ?
> >  - add memory.shrink_usage_to file.
> > 
> > It's long way to what I really want to do....
> > 
> 
> Yes a long way to go, I want to add
> 
> 1) Multi-hierarchy support
> 2) Support for soft-limits
> 3) get swappiness working (there are patches posted for it by Yamamoto-San, but
> something is broken, I suspect even in global swappiness).
> 
> 
> 
> > 
> > Thanks,
> > -Kame
> 
> 
> -- 
> 	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