linux-kernel - Re: [PATCH 9/13] memcg: lookup page cgroup (and remove pointer from struct 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: <48D9FAFF.8070404@linux.vnet.ibm.com>
Date:	Wed, 24 Sep 2008 01:31:59 -0700
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>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 9/13] memcg: lookup page cgroup (and remove pointer from
 struct page)

KAMEZAWA Hiroyuki wrote:
> On Wed, 24 Sep 2008 07:39:58 +0530
> "Balbir Singh" <balbir@...ux.vnet.ibm.com> wrote:
>>> I'll add FLATMEM/DISCONTIGMEM/SPARSEMEM support directly.
>>> I already have wasted a month on this not-interesting work and want to fix
>>> this soon.
>>>
>> Let's look at the basic requirement, make memory resource controller
>> not suck with 32 bit systems. I have been thinking of about removing
>> page_cgroup from struct page only for 32 bit systems (use radix tree),
>> 32 bit systems can have a maximum of 64GB if PAE is enabled, I suspect
>> radix tree should work there and let the 64 bit systems work as is. If
>> performance is an issue, I would recommend the 32 bit folks upgrade to
>> 64 bit :) Can we build consensus around this approach?
>>
> My thinking is below. (assume 64bit)
> 

assume 64 bit for the calculations below?

>   - remove page_cgroup pointer from struct page allows us to reduce
>     static memory usage at boot by 8bytes/4096bytes if memory cgroup is disabled.
>     This reaches 96MB on my 48 GB box. I think this is big.
>   - pre-allocation of page_cgroup gives us following.
>    Pros.
>       - We are not necessary to be afraid of "failure of kmalloc" and
>         "goes down to memory reclaim at kmalloc"
>         This makes memory resource controller much simpler and robust.
>       - We can know what amount of kernel memory will be used for
>         LRU pages management.
>    Cons.
>       - All page_cgroups are allocated at boot.
>         This reaches 480MB on my 48GB box.
> 
>   But I think we can ignore "Cons.". If we use up memory, we'll use tons of
>   page_cgroup. Considering memory fragmentation caused by allocating a lots of
>   very small object, pre-allocation makes memcg better.

This looks like a good patch. I'll review and test it.

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