Re: [PATCH 4/7] memcg: page migration

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Tue, 18 Mar 2008 23:41:41 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2008-03-14 19:15:43]:
> 
> > Christoph Lameter, writer of page migraion, suggested me that
> > new page_cgroup should be assignd to new page at page is allocated.
> > This patch changes migration path to assign page_cgroup of new page
> > at allocation.
> > 
> > Pros:
> >  - We can avoid compliated lock depndencies.
> > Cons:
> >  - Have to handle a page which is not on LRU in memory resource controller.
> > 
> > For pages not-on-LRU, I added PAGE_CGROUP_FLAG_MIGRATION and
> > mem_cgroup->migrations counter.
> > (force_empty will not end while migration because new page's
> >  refcnt is alive until the end of migration.)
> > 
> > I think this version simplifies complicated lock dependency in page migraiton,
> > but I admit this adds some hacky codes. If you have good idea, please advise me.
> > 
> > Works well under my tests.
> 
> This code is easier to read as well. I think this a good approach. To
> be honest, I've not had the chance to test page migration very often.
> Should we update Documentation/controllers/memory.txt to indicate that
> migration might prevent force_empty and hence rmdir() from working?
> 
I'm now rewriting this code to use 'list' instead of a counter but
reconsidering this care is really necessary or not.

Because !Page_lru pages are already handled in mem_cgroup_isolate_page(),
we don't have to do something special to non-LRU pages.

I'd like to drop this care-nolru-pages check today and check it.

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>