On Wed, Apr 07, 2010 at 05:11:13PM +0900, KAMEZAWA Hiroyuki wrote:
quoted text
> On Wed, 7 Apr 2010 10:00:14 +0200
> Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> > Probably a stupid question: but isn't it possible to allocate the huge
> > amounts of memory only if somebody activates memcg during runtime?
> 
> Activation can occur only at boot but page_cgroup allocation happens at
> memory hotplug.
> 
> > And then allocate everything using vmalloc?
> No.
> 
> > But that probably doesn't work, since you need to record everything
> > from the boot of the system, I would guess?
> 
> The story was..
> 
> 1. at first, page_cgroup was allocated on demand. but we need to have
>    page->page_cgroup pointer. Then, we pay 8bytes per page even if we
>    disable memory cgroup.
>    All page behavior was tracked since boot time.
> 
> 2. Fedora maintaienr said "we never enable memcg if you contiue to use
>    page->page_cgroup pointer, 8bytes per page costs!".
>    Then, we decieded to allocate page_cgroup at boot time, and allocate
>    all at once at boot time. This makes memcg runtime robust. And we
>    got rid of page->page_cgroup pointer.
>    cgroup_disable=memory user have no waste of memory now.
> 
> > Just wondering because we do everything to not even waste a single bit
> > in struct page and all of a sudden on the enterprise distros we allocate
> > (by default!) 40 additional bytes per page.
> 
> 3. Then, I added warning when I wrote a patch to allocate page_cgroup at boot.
>    It's easy to avoid extra 40bytes.
>    For enterprise, I have no concern. Enterprise admin tend to be careful and
>    check all default value when he use a new kernel.
>    That message was for desktop guys using desktop distro.
> 
>    Disabling memory cgroup at default may be a choice. But no one send such kind
>    of patch until now.

Thanks for explaining! Looks like whatever you do there's always somebody
who complains.
Distros _could_ ship with memcg by default off independently of the upstream
kernel. But it looks like they won't. Anyway that's a problem we can't solve
here.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/