On Thu, Jun 02, 2011 at 08:52:47AM +0900, Hiroyuki Kamezawa wrote: > 2011/6/1 Johannes Weiner <hannes@xxxxxxxxxxx>: > > Hi, > > > > this is the second version of the memcg naturalization series. The > > notable changes since the first submission are: > > > > o the hierarchy walk is now intermittent and will abort and > > remember the last scanned child after sc->nr_to_reclaim pages > > have been reclaimed during the walk in one zone (Rik) > > > > o the global lru lists are never scanned when memcg is enabled > > after #2 'memcg-aware global reclaim', which makes this patch > > self-sufficient and complete without requiring the per-memcg lru > > lists to be exclusive (Michal) > > > > o renamed sc->memcg and sc->current_memcg to sc->target_mem_cgroup > > and sc->mem_cgroup and fixed their documentation, I hope this is > > better understandable now (Rik) > > > > o the reclaim statistic counters have been renamed. there is no > > more distinction between 'pgfree' and 'pgsteal', it is now > > 'pgreclaim' in both cases; 'kswapd' has been replaced by > > 'background' > > > > o fixed a nasty crash in the hierarchical soft limit check that > > happened during global reclaim in memcgs that are hierarchical > > but have no hierarchical parents themselves > > > > o properly implemented the memcg-aware unevictable page rescue > > scanner, there were several blatant bugs in there > > > > o documentation on new public interfaces > > > > Thanks for your input on the first version. > > > > I ran microbenchmarks (sparse file catting, essentially) to stress > > reclaim and LRU operations. There is no measurable overhead for > > !CONFIG_MEMCG, memcg disabled during boot, memcg enabled but no > > configured groups, and hard limit reclaim. > > > > I also ran single-threaded kernbenchs in four unlimited memcgs in > > parallel, contained in a hard-limited hierarchical parent that put > > constant pressure on the workload. There is no measurable difference > > in runtime, the pgpgin/pgpgout counters, and fairness among memcgs in > > this test compared to an unpatched kernel. Needs more evaluation, > > especially with a higher number of memcgs. > > > > The soft limit changes are also proven to work in so far that it is > > possible to prioritize between children in a hierarchy under pressure > > and that runtime differences corresponded directly to the soft limit > > settings in the previously described kernbench setup with staggered > > soft limits on the groups, but this needs quantification. > > > > Based on v2.6.39. > > > > 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 > 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. > 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... > 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 > 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! -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>