Re: page allocation failure when cached memory is close to the total memory.

[Nick Piggin <nickpiggin@yahoo.com.au>]

Aubrey wrote:
> On 3/1/06, Andrew Morton <akpm@osdl.org> wrote:
>
> > You mean 10MB.
>
> Sorry for the typo.
>
>
> > The chances of finding 10MB of contiguous free pages are basically nil, so
> > the page allocator doesn't even try to free up pages to attempt to satisfy
> > such a large request.  If it can't find the 10MB of free memory
> > immediately, it just gives up.
>
>
> Nope. I've tested the case on the host. See below. The allocation for
> 300MB was sucessful when the cached memory was close to the total
> memory.
>
> Any thoughts why?

At a guess, this machine is using an mmu and a kernel compiled with
CONFIG_MMU, while the previous one wasn't?

Having an mmu means that all userspace allocations can be satisfied
with arbitrary collections of pages, not having one means you need
a linear area of physical memory of the required size.

I've never used one of those nommu systems, but I imagine that there
are conventions that need to be used that don't exist with general
purpose systems.

To start with: I'd try really hard to keep allocations <= 4k, even
if that means inefficiencies (eg building your own "page tables" in
the form of a radix tree, or using a list or other data structure to
allocate even a simple vector like you have there).

If you really need a big linear area, allocate this once when your
system boots and keep it allocated forever. You could even write
a custom allocator to manage this area, for example.

But asking on the uclinux list would probably be your best bet.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/