Re: [PATCH 0/12] memcg updates v5

[Balbir Singh <balbir@linux.vnet.ibm.com>]

KAMEZAWA Hiroyuki wrote:
> On Fri, 26 Sep 2008 19:36:02 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> 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)
> 

Yes, sounds reasonable

> 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)

without (3), don't we have a problem pushing (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)
> 

I think (9) is probably the most important. I'll review it today

> 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....
> 

Yes a long way to go, I want to add

1) Multi-hierarchy support
2) Support for soft-limits
3) get swappiness working (there are patches posted for it by Yamamoto-San, but
something is broken, I suspect even in global swappiness).



> 
> Thanks,
> -Kame


-- 
	Balbir