linux-kernel - Re: [PATCH 0/12] memcg updates v5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Sep 2008 08:32:07 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
CC:	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>,
	"xemul@...nvz.org" <xemul@...nvz.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Dave Hansen <haveblue@...ibm.com>, ryov@...inux.co.jp,
	YAMAMOTO Takashi <yamamoto@...inux.co.jp>
Subject: Re: [PATCH 0/12] memcg updates v5

KAMEZAWA Hiroyuki wrote:
> On Fri, 26 Sep 2008 19:36:02 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/