[PATCH] powerpc: enforce sane MAX_ORDER

[Kumar Gala]

On Sep 24, 2008, at 9:13 AM, Johannes Berg wrote:

> On Wed, 2008-09-24 at 09:05 -0500, Kumar Gala wrote:
>
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -415,8 +415,11 @@ config PPC_64K_PAGES
>>>
>>> config FORCE_MAX_ZONEORDER
>>> 	int "Maximum zone order"
>>> +	range 9 999 if PPC_64K_PAGES
>>> 	default "9" if PPC_64K_PAGES
>>> +	range 13 999 if PPC64 && !PPC_64K_PAGES
>>> 	default "13" if PPC64 && !PPC_64K_PAGES
>>> +	range 11 999
>>> 	default "11"
>>> 	help
>>> 	  The kernel memory allocator divides physically contiguous memory
>>
>> Hope about setting the upper bound to 32 or 64.
>
> Works for me, I'm interested in the lower bound because if you set
> CONFIG_PM on a machine with dart iommu and set this to 9 then the  
> thing
> will BUG_ON during boot.
>
>> Since I believe this
>> in effect 2^FORCE_MAX_ZONEORDER, so 999 is just insane.
>
> Indeed it is, and no argument that it's insane. But it's not limited  
> at
> all right now, so you can in theory set it to 10000, write a kernel
> module that calls alloc_pages(1000) and have it fail because not  
> enough
> memory is available, rather than failing because of the MAX_ORDER  
> check.
>
>> I'd almost
>> prefer something like 16 since that might still be in the realm of
>> reasonable and able to work.
>
> with 4k pages that would be 256M memory, that seems well possible to
> allocate. Even 20 might still be possible (4G memory) if you  
> allocate it
> early enough at boot and have a lot of memory (on a 64-bit system).
>
> On the other hand, why bother limiting it? If people set it too  
> large in
> their config all that will happen is that it takes a bit longer to  
> fail
> to allocate such a ridiculous amount of memory.

We'll I'm ok with that, but I dont think we should be values that make  
no sense.  64 would seem the max even in a 64-bit system.

- k