* KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> [2010-12-07 15:24:23]: > On Tue, 7 Dec 2010 11:45:03 +0530 > Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote: > > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> [2010-11-30 17:54:43]: > > > > > On Tue, 30 Nov 2010 17:27:10 +0900 > > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > > > > > > > On Tue, 30 Nov 2010 17:15:37 +0900 > > > > Minchan Kim <minchan.kim@xxxxxxxxx> 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@xxxxxxxxxx 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@xxxxxxxxx";> email@xxxxxxxxx </a>