linux-kernel - Re: [RFC][PATCH 4/7][memcg] memcg use ID in page

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]

Message-ID: <4C505025.1040709@ds.jp.nec.com>
Date:	Wed, 28 Jul 2010 11:43:33 -0400
From:	Munehiro Ikeda <m-ikeda@...jp.nec.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>,
	"balbir@...ux.vnet.ibm.com" <balbir@...ux.vnet.ibm.com>,
	gthelen@...gle.com,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 4/7][memcg] memcg use ID in page_cgroup

Vivek Goyal wrote, on 07/27/2010 11:13 PM:
> On Wed, Jul 28, 2010 at 11:44:02AM +0900, KAMEZAWA Hiroyuki wrote:
>> On Tue, 27 Jul 2010 22:39:04 -0400
>> Vivek Goyal<vgoyal@...hat.com>  wrote:
>>
>>> On Tue, Jul 27, 2010 at 04:56:29PM +0900, KAMEZAWA Hiroyuki wrote:
>>>> From: KAMEZAWA Hiroyuki<kamezawa.hiroyu@...fujitsu.com>
>>>>
>>>> Now, addresses of memory cgroup can be calculated by their ID without complex.
>>>> This patch relplaces pc->mem_cgroup from a pointer to a unsigned short.
>>>> On 64bit architecture, this offers us more 6bytes room per page_cgroup.
>>>> Use 2bytes for blkio-cgroup's page tracking. More 4bytes will be used for
>>>> some light-weight concurrent access.
>>>>
>>>> We may able to move this id onto flags field but ...go step by step.
>>>>
>>>> Signed-off-by: KAMEZAWA Hiroyuki<kamezawa.hiroyu@...fujitsu.com>
>>>> ---
>>>>   include/linux/page_cgroup.h |    3 ++-
>>>>   mm/memcontrol.c             |   40 +++++++++++++++++++++++++---------------
>>>>   mm/page_cgroup.c            |    2 +-
>>>>   3 files changed, 28 insertions(+), 17 deletions(-)
>>>>
>>>> Index: mmotm-0719/include/linux/page_cgroup.h
>>>> ===================================================================
>>>> --- mmotm-0719.orig/include/linux/page_cgroup.h
>>>> +++ mmotm-0719/include/linux/page_cgroup.h
>>>> @@ -12,7 +12,8 @@
>>>>    */
>>>>   struct page_cgroup {
>>>>   	unsigned long flags;
>>>> -	struct mem_cgroup *mem_cgroup;
>>>> +	unsigned short mem_cgroup;	/* ID of assigned memory cgroup */
>>>> +	unsigned short blk_cgroup;	/* Not Used..but will be. */
>>>
>>> So later I shall have to use virtually indexed arrays in blkio controller?
>>> Or you are just using virtually indexed arrays for lookup speed and
>>> I can continue to use css_lookup() and not worry about using virtually
>>> indexed arrays.
>>>
>> yes. you can use css_lookup() even if it's slow.
>>
>
> Ok.
>
>>> So the idea is that when a page is allocated, also store the blk_group
>>> id and once that page is submitted for writeback, we should be able
>>> to associate it to right blkio group?
>>>
>> blk_cgroup id can be attached whenever you wants. please overwrite
>> page_cgroup->blk_cgroup when it's necessary.
>
>> Did you read Ikeda's patch ? I myself doesn't have patches at this point.
>> This is just for make a room for recording blkio-ID, which was requested
>> for a year.
>
> I have not read his patches yet. IIRC, previously there were issues
> regarding which group should be charged for the page. The person who
> allocated it or the thread which did last write to it etc... I guess
> we can sort that out later.

Absolutely.
iotrack, a part of blkio cgroup for async write patch I posted, charges
the thread (in exact, blkio-cgroup to which the thread belongs) which
dirtied the page first.  Though it should be controversial and we need
to discuss who should be charged, adding pc->blk_cgroup has no problem
because blkio-cgroup can overwrite it any time, as Kame said above.

Beyond that, adding pc->blk_cgroup is a big step for us.  Now I encode
and store ID in pc->flags.  pc->blk_cgroup is more straight and that
is what we have been looking forward.  Thanks Kame!



-- 
IKEDA, Munehiro
   NEC Corporation of America
     m-ikeda@...jp.nec.com

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