lkml.org 
[lkml]   [2008]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@linux.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


\
 
 \ /
  Last update: 2008-09-24 10:37    [W:0.121 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site