CONFIG_FORCE_MAX_ZONEORDER settable for all ARM architectures
Hi,
on a PXA3xx based platform, we want to allocate 8MByte of physically contiguous memory for the framebuffer device.
However, alloc_pages() fails because MAX_ORDER is hard-coded to 11 for this architecture.
Is there any reason why CONFIG_FORCE_MAX_ZONEORDER is constrained to ARCH_SHMOBILE in arch/arm/Kconfig? Would a patch to remove this limitation be accepted? Or is there any better way to allocate that amount and type of memory?
Thanks,
Daniel
Quoted 5 lines · Daniel Mack
Hi,
on a PXA3xx based platform, we want to allocate 8MByte of physically contiguous memory for the framebuffer device.
Quoted 8 lines
However,
alloc_pages()fails becauseMAX_ORDERis hard-coded to 11 for this architecture.Is there any reason why
CONFIG_FORCE_MAX_ZONEORDERis constrained toARCH_SHMOBILEinarch/arm/Kconfig? Would a patch to remove this limitation be accepted? Or is there any better way to allocate that amount and type of memory?
There is actually an on-going discussion of memory region allocator, basically can
be used to solve the allocation of large chunk of physically contiguous memory by
memory migration at run-time. Some of the ideas were mentioned in a previous patch of CMA (contiguous memory allocator)? Though I didn't look too much into that thread.
However, I'm not really sure about how the size of the memory region is chosen and if the MAX_ORDER issue can be solved as well. So I guess before that happens in mainline, would be acceptable to adjust MAX_ZONEORDER in a hackish way.
Quoted 8 lines
Thanks,
Daniel_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 4 lines · Eric Miao
However, I'm not really sure about how the size of the memory region is chosen and if the
MAX_ORDERissue can be solved as well. So I guess before that happens in mainline, would be acceptable to adjustMAX_ZONEORDERin a hackish way.
Even if you increase MAX_ZONEORDER, the chances of being able to allocate such a large page at runtime will be fairly low due to fragmentation. It's something the normal page allocator has never been very good with.
Quoted 9 lines · Russell King - ARM Linux
Quoted 4 lines · Eric Miao
However, I'm not really sure about how the size of the memory region is chosen and if the
MAX_ORDERissue can be solved as well. So I guess before that happens in mainline, would be acceptable to adjustMAX_ZONEORDERin a hackish way.Even if you increase
MAX_ZONEORDER, the chances of being able to allocate such a large page at runtime will be fairly low due to fragmentation. It's something the normal page allocator has never been very good with.
Well, for us, this does work when we increase this number to 12, and as we build the pxafb statically into the kernel, I would expect the memory fragmentation situation to be deterministic at each boot. I agree we couldn't rely on this when loading the driver as module at some later point.
Thanks,
Daniel
Quoted 5 lines · Daniel Mack
on a PXA3xx based platform, we want to allocate 8MByte of physically contiguous memory for the framebuffer device.
However,
alloc_pages()fails becauseMAX_ORDERis hard-coded to 11 for this architecture.
Wrong. If there's an SA1111, it defaults to 9 rather than 11.
Quoted 2 lines
Is there any reason why
CONFIG_FORCE_MAX_ZONEORDERis constrained toARCH_SHMOBILEinarch/arm/Kconfig?
It's not.
int "Maximum zone order" if ARCH_SHMOBILE
means "present the user with this option if ARCH_SHMOBILE != n, otherwise don't present it to the user but set it anyway".
range 11 64 if ARCH_SHMOBILE
defines the range when ARCH_SHMOBILE is set. When it isn't set, there is no range limitation.
default "9" if SA1111
default "11"So, if SA1111 is set, then it's 9, otherwise it's 11.