Re: [PATCH 1/4] Add kswapd descriptor.

[Balbir Singh <balbir@linux.vnet.ibm.com>]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-12-07 15:24:23]:

> On Tue, 7 Dec 2010 11:45:03 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-11-30 17:54:43]:
> > 
> > > On Tue, 30 Nov 2010 17:27:10 +0900
> > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > 
> > > > On Tue, 30 Nov 2010 17:15:37 +0900
> > > > Minchan Kim <minchan.kim@gmail.com> wrote:
> > > > 
> > > > > Ideally, I hope we unify global and memcg of kswapd for easy
> > > > > maintainance if it's not a big problem.
> > > > > When we make patches about lru pages, we always have to consider what
> > > > > I should do for memcg.
> > > > > And when we review patches, we also should consider what the patch is
> > > > > missing for memcg.
> > > > > It makes maintainance cost big. Of course, if memcg maintainers is
> > > > > involved with all patches, it's no problem as it is.
> > > > > 
> > > > I know it's not. But thread control of kswapd will not have much merging point.
> > > > And balance_pgdat() is fully replaced in patch/3. The effort for merging seems
> > > > not big.
> > > > 
> > > 
> > > kswapd's balance_pgdat() is for following
> > >   - reclaim pages within a node.
> > >   - balancing zones in a pgdat.
> > > 
> > > memcg's background reclaim needs followings.
> > >   - reclaim pages within a memcg
> > >   - reclaim pages from arbitrary zones, if it's fair, it's good.
> > >     But it's not important from which zone the pages are reclaimed from. 
> > >     (I'm not sure we can select "the oldest" pages from divided LRU.)
> > >
> > 
> > Yes, if it is fair, then we don't break what kswapd tries to do, so
> > fairness is quite important, in that we don't leaves zones unbalanced
> > (at least by very much) as we try to do background reclaim. But
> > sometimes it cannot be helped, specially if there are policies that
> > bias the allocation.
> >  
> > > Then, merging will put 2 _very_ different functionalities into 1 function.
> > > 
> > > So, I thought it's simpler to implement
> > > 
> > >  1. a victim node selector (This algorithm will never be in kswapd.)
> > 
> > A victim node selector per memcg? Could you clarify the context of
> > node here?
> > 
> An argument to balance_pgdat_for_memcg() or a start point of zonelist[].
> i.e.
> 	zone_list = NODE_DATA(victim)->zonelist[0 or 1]
> 
> 	for_each_zone_zonelist(z, zone_list)....
> 
> But, this is just an example, we just need to determine where we reclaim
> page from before start walking.
>

OK, I understand. BTW, I am not against integration with kswapd for
watermark based reclaim, the advantage I see is that as we balance
zone/node watermarks, we also balance per memcg watermark. The cost
would be proportional to the size of memcg's that have allocated from
that zone/node. kswapd is not fast path and already optimized in terms
of when to wake up, so it makes sense to reuse all of that. 

-- 
	Three Cheers,
	Balbir

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