Re: [RFC][PATCH 2/6] memcg: handle swap cache

[KAMEZAWA Hiroyuki]

On Fri, 7 Nov 2008 17:53:03 +0900
Daisuke Nishimura <nishimura@xxxxxxxxxxxxxxxxx> wrote:

> On Wed, 5 Nov 2008 17:20:09 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> > SwapCache support for memory resource controller (memcg)
> > 
> > Before mem+swap controller, memcg itself should handle SwapCache in proper way.
> > 
> > In current memcg, SwapCache is just leaked and the user can create tons of
> > SwapCache. This is a leak of account and should be handled.
> > 
> > SwapCache accounting is done as following.
> > 
> >   charge (anon)
> > 	- charged when it's mapped.
> > 	  (because of readahead, charge at add_to_swap_cache() is not sane)
> >   uncharge (anon)
> > 	- uncharged when it's dropped from swapcache and fully unmapped.
> > 	  means it's not uncharged at unmap.
> > 	  Note: delete from swap cache at swap-in is done after rmap information
> > 	        is established.
> >   charge (shmem)
> > 	- charged at swap-in. this prevents charge at add_to_page_cache().
> > 
> >   uncharge (shmem)
> > 	- uncharged when it's dropped from swapcache and not on shmem's
> > 	  radix-tree.
> > 
> >   at migration, check against 'old page' is modified to handle shmem.
> > 
> > Comparing to the old version discussed (and caused troubles), we have
> > advantages of
> >   - PCG_USED bit.
> >   - simple migrating handling.
> > 
> > So, situation is much easier than several months ago, maybe.
> > 
> > Changelog (v1) -> (v2)
> >   - use lock_page() when we handle unlocked SwapCache.
> > 
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
> > 
> I tested this version under swap in/out activity with page migration/rmdir,
> and it worked w/o errors for more than 24 hours.
> 
> 	Reviewed-by: Daisuke Nishimura <nishimura@xxxxxxxxxxxxxxxxx>
> 	Tested-by: Daisuke Nishimura <nishimura@xxxxxxxxxxxxxxxxx>
> 
Thank you!

-Kame

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/