[PATCH] ARM: keystone: allow FORCE_MAX_ZONEORDER to be configurable on Keystone

[m-karicheri2@ti.com (Murali Karicheri)]

Russell,

On 07/01/2015 02:48 PM, Russell King - ARM Linux wrote:
> On Wed, Jul 01, 2015 at 01:53:02PM -0400, Murali Karicheri wrote:
>> Currently for Keystone devices, user can't change the
>> value of CONFIG_FORCE_MAX_ZONEORDER option in defconfig.
>> Users require capability to tune the value of this option on a target
>> board. So this patch adds this capability
>
> No they shouldn't.  If we do permit this, it should not be unrestricted -
> it's a power-of-2 of the page size, so specifying something like 32768 is
> insane.
>

Thanks for your comments

This was present in out internal version of the kernel. Only thing I can 
recall is that this patch was added to fix an isue in a DEBUG buid. 
Memory allocation for a large data structures used by a driver during 
probe (internal version) was failing as the data structure gets expanded 
as a result of DEBUG option related variables. There is no hurry to add 
this for now.

> In any case, it's well known that the Linux MM system fragments memory,
> and the higher order allocations will fail soon after boot - and the
> larger the order, the greater chance of it failing.Ok
>

Agree

> The only case that you want large allocations is for things like DMA, and
> we have a separate allocator for that called CMA, which is able to grab
> large chunks of memory, provided it's configured with a large enough zone.
>
> Please check whether CMA can be used _before_ considering using this
> option.  If you need to increase the order, it should be justified, and
> it should be done on a per SoC basis in a static way, not left to the
> user to dream up some power-of-2 figure.
I will explore these options when we upstream the internal driver. For 
now I will drop this patch.

Thanks
-- 
Murali Karicheri
Linux Kernel, Keystone