CONFIG_FORCE_MAX_ZONEORDER settable for all ARM architectures

CONFIG_FORCE_MAX_ZONEORDER settable for all ARM architectures

[Daniel Mack]

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

CONFIG_FORCE_MAX_ZONEORDER settable for all ARM architectures

[Eric Miao]

On Fri, Nov 5, 2010 at 9:41 PM, Daniel Mack <zonque@gmail.com> wrote:
> 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?
>

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.

> Thanks,
> Daniel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

CONFIG_FORCE_MAX_ZONEORDER settable for all ARM architectures

[Russell King - ARM Linux]

On Fri, Nov 05, 2010 at 09:41:10AM -0400, Daniel Mack wrote:
> 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.

> 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.

CONFIG_FORCE_MAX_ZONEORDER settable for all ARM architectures

[Russell King - ARM Linux]

On Fri, Nov 05, 2010 at 09:59:41PM +0800, Eric Miao wrote:
> 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.

CONFIG_FORCE_MAX_ZONEORDER settable for all ARM architectures

[Daniel Mack]

On 11/05/2010 10:07 AM, Russell King - ARM Linux wrote:
> On Fri, Nov 05, 2010 at 09:59:41PM +0800, Eric Miao wrote:
>> 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