2011/6/2 Johannes Weiner [off-list ref]:

On Thu, Jun 02, 2011 at 08:52:47AM +0900, Hiroyuki Kamezawa wrote:

quoted

2011/6/1 Johannes Weiner [off-list ref]:
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.

quoted

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.

quoted

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.

quoted

  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

quoted

5. please write documentation to explain what new LRU do.

Ok.

quoted

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@kvack.org.  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@kvack.org"> email@kvack.org </a>