Re: [PATCH 3/4] Per cgroup background reclaim.

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

On Wed,  1 Dec 2010 11:18:45 +0900 (JST)
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:

> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index a15bc1c..dc61f2a 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -615,6 +615,7 @@ static void free_pcppages_bulk(struct zone *zone, int count,
> >  
> >  		do {
> >  			page = list_entry(list->prev, struct page, lru);
> > +			mem_cgroup_clear_unreclaimable(page, zone);
> >  			/* must delete as __free_one_page list manipulates */
> >  			list_del(&page->lru);
> >  			/* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
> > @@ -632,6 +633,7 @@ static void free_one_page(struct zone *zone, struct page *page, int order,
> >  	spin_lock(&zone->lock);
> >  	zone->all_unreclaimable = 0;
> >  	zone->pages_scanned = 0;
> > +	mem_cgroup_clear_unreclaimable(page, zone);
> >  
> >  	__free_one_page(page, zone, order, migratetype);
> >  	__mod_zone_page_state(zone, NR_FREE_PAGES, 1 << order);
> 
> Please don't do that. free page is one of fast path. We don't want to add
> additonal overhead here.
> 
> So I would like to explain why we clear zone->all_unreclaimable in free 
> page path at first. Look, zone free pages are maintained by NR_FREE_PAGES
> and free_one_page modify it.
> 
> But, free_one_page() is unrelated to memory cgroup uncharge thing. If nobody
> does memcg uncharge, reclaim retrying is pointless. no? I think we have
> better place than here.
> 
I agree. Should be done in uncharge or event counter.

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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>