Re: [GIT PATCH] x86,percpu: fix pageattr handling with remap allocator

Jan Beulich
2009-05-15T08:22:20Z

>>> Tejun Heo <tj@kernel.org> 15.05.09 10:11 >>>
>>>> This would additionally address a potential problem on 32-bits -
>>>> currently, for a 32-CPU system you consume half of the vmalloc space
>>>> with PAE (on non-PAE you'd even exhaust it, but I think it's
>>>> unreasonable to expect a system having 32 CPUs to not need PAE).
>>> I recall having about the same conversation before. Looking up...
>>>
>>> -- QUOTE --
>>> Actually, I've been looking at the numbers and I'm not sure if the
>>> concern is valid. On x86_32, the practical number of maximum
>>> processors would be around 16 so it will end up 32M, which isn't
>>> nice and it would probably a good idea to introduce a parameter to
>>> select which allocator to use but still it's far from consuming all
>>> the VM area. On x86_64, the vmalloc area is obscenely large at 245,
>>> ie 32 terabytes. Even with 4096 processors, single chunk is measly
>>> 0.02%.
>>
>> Just to note - there must be a reason we (SuSE/Novell) build our default
>> 32-bit kernel with support for 128 CPUs, which now is simply broken.
>
>It's not broken, it will just fall back to 4k allocator. Also, please

I'm afraid I have to disagree: There's no check (not even in
vm_area_register_early()) whether the vmalloc area is actually large enough
to fulfill the request.

>take a look at the refreshed patchset, remap allocator is not used
>anymore if it's gonna occupy more than 20% (random number from the top
>of my head) of vmalloc area.

Yeah, I saw this only after following this thread.

Jan