2011/6/2 Johannes Weiner <hannes@xxxxxxxxxxx>: > On Thu, Jun 02, 2011 at 08:52:47AM +0900, Hiroyuki Kamezawa wrote: >> 2011/6/1 Johannes Weiner <hannes@xxxxxxxxxxx>: >> Hmm, I welcome and will review this patches but.....some points I want to say. >> >> 1. No more conflict with Ying's work ? >> Could you explain what she has and what you don't in this v2 ? >> If Ying's one has something good to be merged to your set, please >> include it. > > The problem is that the solution we came up with at LSF, i.e. the > one-dimensional linked list of soft limit-exceeding memcgs, is not > adequate to represent the hierarchy structure of memcgs. > > My solution is fundamentally different, so I don't really see possible > synergy between the patch series right now. > > This was the conclusion last time: > http://marc.info/?l=linux-mm&m=130564056215365&w=2 > Hmm, will look. IIUC, current design of per-zone tree is for supoorting current policy in efficient way as "pick up the largest usage excess memcg" If we change policy, it's natural to make changes in implementation. >> 2. it's required to see performance score in commit log. > > The patch series is not a performance optimization. But I can include > it to prove there are no regressions. > yes, it's helpful. >> 4. This work can be splitted into some small works. >> a) fix for current code and clean ups >> a') statistics >> b) soft limit rework >> c) change global reclaim >> >> I like (a)->(b)->(c) order. and while (b) you can merge your work >> with Ying's one. >> And for a') , I'd like to add a new file memory.reclaim_stat as I've >> already shown. >> and allow resetting. > > Resetting reclaim statistics is a nice idea, let me have a look. > Sorry, I am a bit behind on reviewing other patches... > I think I'll cut-out the patch and merge it before my full work. >> Hmm, how about splitting patch 2/8 into small patches and see what happens in >> 3.2 or 3.3 ? While that, we can make softlimit works better. >> (and once we do 2/8, our direction will be fixed to the direction to >> remove global LRU.) > > Do you have specific parts in mind that could go stand-alone? > > One thing I can think of is splitting up those parts: > > 1. move /target/ reclaim to generic code > > 2. convert /global/ reclaim from global lru to hierarchy reclaim > including root_mem_cgroup > Hmm, at brief look patch 2/8 - hierarchy walk rewrite code should be stand alone and can be merged 1st, as clean-up - root cgroup LRU handling was required for performance. I think we removed tons of atomic ops and can remove that special handling personally. But this change of root cgroup handling should be in separate patch. with performance report. .... I'll do close look later, sorry. -Kame >> 5. please write documentation to explain what new LRU do. > > Ok. > >> BTW, after this work, lists of ROOT cgroup comes again. I may need to check >> codes which see memcg is ROOT or not. Because we removed many atomic >> ops in memcg, I wonder ROOT cgroup can be accounted again.. > > Oh, please do if you can find the time. The memcg lru rules are > scary! > IIRC, It was requested by Red*at ;) Thanks, -Kame -- 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 internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href