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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
