Re: [PATCH 1/2] memcg: consistently use vmalloc for page_cgroup allocations

[Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>]

On Fri, Apr 05, 2013 at 02:01:11PM +0400, Glauber Costa wrote:
> Right now, allocation for page_cgroup is a bit complicated, dependent on
> a variety of system conditions:
> 
> For flat memory, we are likely to need quite big pages, so the page
> allocator won't cut. We are forced to init flatmem mappings very early,
> because if we run after the page allocator is in place those allocations
> will be denied. Flatmem mappings thus resort to the bootmem allocator.
> 
> We can fix this by using vmalloc for flatmem mappings. However, we now
> have the situation in which flatmem mapping allocate using vmalloc, but
> sparsemem may or may not allocate with vmalloc. It will try the
> page_allocator first, and retry vmalloc if it fails.

Vmalloc space is a precious resource on 32-bit systems and harder on
the TLB than the identity mapping.

It's a last resort thing for when you need an unusually large chunk of
contiguously addressable memory during runtime, like loading a module,
buffers shared with userspace etc..  But here we know, during boot
time, the exact amount of memory we need for the page_cgroup array.

Code cleanup is not a good reason to use vmalloc in this case, IMO.