Re: RFC [Patch] Remove "please try 'cgroup_disable=memory' optionif you don't want memory cgroups" printk at boot time.
From: Heiko Carstens
Date: Wed Apr 07 2010 - 04:32:52 EST
On Wed, Apr 07, 2010 at 05:11:13PM +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 7 Apr 2010 10:00:14 +0200
> Heiko Carstens <heiko.carstens@xxxxxxxxxx> 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?
> > 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
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
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/