Re: Possible deadloop in direct reclaim?

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Wed, Jul 31, 2013 at 10:19:53PM -0700, Lisa Du wrote:
> >fork alloc order-1 memory for stack. Where and why alloc order-2? If it is
> >arch specific code, please
> >contact arch maintainer.
> Yes arch do_fork allocate order-2 memory when copy_process. 
> Hi, Russel
> What's your opinion about this question?  
> If we really need order-2 memory for fork, then we'd better set
> CONFIG_COMPATION right?

Well, I gave up trying to read the original messages because the quoting
style is a total mess, so I don't have a full understanding of what the
issue is.

However, we have always required order-2 memory for fork, going back to
the 1.x kernel days - it's fundamental to ARM to have that.  The order-2
allocation os for the 1st level page table.  No order-2 allocation, no
page tables for the new thread.

Looking at this commit:

commit 05106e6a54aed321191b4bb5c9ee09538cbad3b1
Author: Rik van Riel <riel@redhat.com>
Date:   Mon Oct 8 16:33:03 2012 -0700

    mm: enable CONFIG_COMPACTION by default

    Now that lumpy reclaim has been removed, compaction is the only way left
    to free up contiguous memory areas.  It is time to just enable
    CONFIG_COMPACTION by default.

it seems to indicate that everyone should have this enabled - however,
the way the change has been done, anyone building from defconfigs before
that change will not have that option enabled.

So yes, this option should be turned on.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>