Re: [PATCH 0/12] memcg updates v5

[KAMEZAWA Hiroyuki]

On Fri, 26 Sep 2008 19:36:02 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:

> > I think (1) might be OK, except for the accounting issues pointed out (change in
> > behaviour visible to end user again, sigh! :( ).
> But it was just a BUG from my point of view...
> 
> > Is (1) a serious issue? 
> considering force_empty(), it's serious.
> 
> > (2) seems OK, except for the locking change for mark_page_accessed. I am looking at
> > (4) and (6) currently.
> > 

I'll do in following way in the next Monday.
Divide patches into 2 set

in early fix/optimize set.
  - push (2)
  - push (4)
  - push (6)
  - push (1)

drops (3).

I don't want to remove all? pages-never-on-LRU before fixing force_empty.

in updates
  - introduce atomic flags. (5)
  - add move_account() function (7)
  - add memory.attribute to each memcg dir. (NEW)
  - enhance force_empty (was (8))
       - remove "forget all" logic. and add attribute to select following 2 behavior
          - call try_to_free_page() until the usage goes down to 0.
            This allows faiulre (if page is mlocked, we can't do.). (NEW)
          - call move_account() to move all charges to its parent (as much as possible) (NEW)
          In future, I'd liket to add trash-box cgroup for force_empty somewhere.
  - allocate all page cgroup at boot (9)
  - lazy lru free/add (10,11) with fixes.
  - fix race at charging swap. (12)

After (9), all page and page_cgroup has one-to-one releationship and we want to
assume that "if page is alive and on LRU, it's accounted and has page_cgroup."
(other team, bio cgroup want to use page_cgroup and I want to make it easy.)

For this, fix to behavior of force_empty..."forget all" is necessary.
SwapCache handling is also necessary but I'd like to postpone until next set
because it's complicated.

After above all.
 - handle swap cache 
 - Mem+Swap controller.
 - add trashbox feature ?
 - add memory.shrink_usage_to file.

It's long way to what I really want to do....


Thanks,
-Kame








  - 




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/