Re: [mmotm][PATCH 1/4] replacement-for-memcg-simple-migration-handling.patch

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

On Tue, 2 Dec 2008 10:05:31 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2008-12-02 13:18:40]:
> 
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > 
> > Now, management of "charge" under page migration is done under following
> > manner. (Assume migrate page contents from oldpage to newpage)
> > 
> >  before
> >   - "newpage" is charged before migration.
> >  at success.
> >   - "oldpage" is uncharged at somewhere(unmap, radix-tree-replace)
> >  at failure
> >   - "newpage" is uncharged.
> >   - "oldpage" is charged if necessary (*1)
> > 
> > But (*1) is not reliable....because of GFP_ATOMIC.
> >
> 
> Kamezawa,
> 
> You did share page migration test cases with me, but I would really
> like to see a page migration test scenario or rather a set of test
> scenarios for the memory controller. Sudhir has added some LTP test
> cases, but for now I would be satisfied with Documentation updates for
> testing the various memory controller features (sort of build a
> regression set of cases in documented form and automate it later). I
> can start with what I have, I would request you to update the
> migration cases and any other case you have. 
> 
Hmm. will consider some. 
But there is not some much "features" of memcg. Just "handlers" for some
memory jobs. So please be careful what is API we must keep and what is
current behavior.

-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>