powerpc: enforce sane MAX_ORDER

powerpc uses CONFIG_FORCE_MAX_ZONEORDER, and some things depend on it
being at least 10 when 64k pages are not configured (notably the dart
iommu code with CONFIG_PM). The defaults are fine, but when going from a
64K pages config to one without 64K pages, MAX_ORDER stays at 9 which is
too low for 4K pages.

This patch makes the Kconfig enforce at least the defaults, I used 999
as the upper bound for no particular reason other than that it's plenty.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---

On Sep 24, 2008, at 8:24 AM, Johannes Berg wrote:

> powerpc uses CONFIG_FORCE_MAX_ZONEORDER, and some things depend on it
> being at least 10 when 64k pages are not configured (notably the dart
> iommu code with CONFIG_PM). The defaults are fine, but when going  
> from a
> 64K pages config to one without 64K pages, MAX_ORDER stays at 9  
> which is
> too low for 4K pages.
>
> This patch makes the Kconfig enforce at least the defaults, I used 999
> as the upper bound for no particular reason other than that it's  
> plenty.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
>
> --- 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.  Since I believe this  
in effect 2^FORCE_MAX_ZONEORDER, so 999 is just insane.  I'd almost  
prefer something like 16 since that might still be in the realm of  
reasonable and able to work.

- k

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.

johannes

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