[PATCH] powerpc: enforce sane MAX_ORDER

[Johannes Berg]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080924/530ff9d6/attachment.pgp>