Re: [PATCH 9/13] memcg: lookup page cgroup (and remove pointer fromstruct page)

[KAMEZAWA Hiroyuki]

On Wed, 24 Sep 2008 01:31:59 -0700
Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:

> KAMEZAWA Hiroyuki wrote:
> > On Wed, 24 Sep 2008 07:39:58 +0530
> > "Balbir Singh" <balbir@xxxxxxxxxxxxxxxxxx> 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?
> 
yes.

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

At least, I should handle "use vmalloc if kmalloc fails" case.
But will not have no major updates. I'll update the whole to the newest
mmotm and post tomorrow if I can start test tonight.

Thanks,
-Kame


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/