Skip to contentSkip to conversation

CONFIG_FORCE_MAX_ZONEORDER settable for all ARM architectures

DISCUSSION Daniel Mack 3 participants 5 messages Nov 5, 2010

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
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 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?

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

#2 lore raw
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_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.

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.

#3 lore raw
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_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.

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

#4 lore raw
In reply to Daniel Mack
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 because MAX_ORDER is 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_ZONEORDER is constrained to ARCH_SHMOBILE in arch/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.