Hi all,
I'm working on the blackfin uclinux. And the kernel version is 2.6.12.
I have an application to malloc 0Mb memory. When cached memory is
small, the allocation will be successful.
But when the cached memory is close to the total memory. The
applicaton memory allocation will fail. See below. I think the cached
memory should be released when there is no enough free memory to
allocate. So far no idea what's wrong. Did anyone ever run into the
problem? Many thanks to your any suggestions and comments.
Regards,
-Aubrey
=========================================================
root:/mnt> cat /proc/meminfo
MemTotal: 54600 kB
MemFree: 6228 kB
Buffers: 2340 kB
Cached: 38464 kB
SwapCached: 0 kB
Active: 11432 kB
Inactive: 29348 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 54600 kB
LowFree: 6228 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 6904 kB
Writeback: 0 kB
Mapped: 0 kB
Slab: 7292 kB
CommitLimit: 27300 kB
Committed_AS: 0 kB
PageTables: 0 kB
VmallocTotal: 0 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
root:/mnt> ../ma
ma: page allocation failure. order:12, mode:0xd0
Stack from 0137bddc:<0>
<0> 00000000<0> 00024cb0<0> 00072b88<0>
036b8220<0> 0000000c<0> 000000d0<0>
00000000<0> 00000000<0>
<0> 00000010<0> 00000000<0> 001be5ec<0>
000270c6<0> 001bf760<0> 001bf640<0>
001be5e0<0> 00000001<0>
<0> 00000000<0> 000000d0<0> 00000000<0>
0000001f<0> 00000000<0> 00102758<0>
0000000e<0> 00000001<0>
<0> 000000d0<0> 0304ca60<0> 00026e8e<0>
00000000<0> 0270bb60<0> 00000021<0>
0000ffff<0> 00000073<0>
<0> 00000000<0> 00000004<0> 00000000<0>
0002aee0<0> 00000000<0> 0002b19c<0>
00000003<0> 001035bc<0>
<0> 03576c00<0> 0000000e<0> 00000021<0>
0368f00c<0> 009f7d54<0> 0002d460<0>
00000004<0> 00a00000<0>
Call Trace:<0>
<0> [<00003706>]<0>
[<0002d55e>]<0> [<00006f3e>]<0>
[<000036a4>]<0>
<0> [<00008000>]<0>
[<00007cd4>]<0> [<00001004>]<0>
Allocation of length 10485760 from process 144 failed
DMA per-cpu: empty
Normal per-cpu:
cpu 0 hot: low 14, high 42, batch 7
cpu 0 cold: low 0, high 14, batch 7
HighMem per-cpu: empty
Free pages: 7536kB (0kB HighMem)
Active:2794 inactive:7321 dirty:1725 writeback:1 unstable:0 free:1884
slab:1564 mapped:0 pagetables:0
DMA free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB
present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 55 55
Normal free:7536kB min:948kB low:1184kB high:1420kB active:11176kB
inactive:29284kB present:56320kB pages_scanned:0 all_unreclaimable?
no
lowmem_reserve[]: 0 0 0
HighMem free:0kB min:128kB low:160kB high:192kB active:0kB
inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: empty
Normal: 58*4kB 7*8kB 3*16kB 1*32kB 0*64kB 0*128kB 0*256kB 6*512kB
4*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 7536kB
HighMem: empty
Alloc failed
================================================================
Aubrey <[email protected]> wrote:
>
> I'm working on the blackfin uclinux. And the kernel version is 2.6.12.
> I have an application to malloc 0Mb memory.
You mean 10MB.
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.
On 3/1/06, Andrew Morton <[email protected]> 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?
Thanks,
-Aubrey
=============================================================
aubrey@linux:~/cvs/kernel/uClinux-dist> cat /proc/meminfo
MemTotal: 1034848 kB
MemFree: 15424 kB
Buffers: 2368 kB
Cached: 751104 kB
SwapCached: 0 kB
Active: 306116 kB
Inactive: 650060 kB
HighTotal: 129560 kB
HighFree: 120 kB
LowTotal: 905288 kB
LowFree: 15304 kB
SwapTotal: 1558296 kB
SwapFree: 1557268 kB
Dirty: 140032 kB
Writeback: 0 kB
Mapped: 265188 kB
Slab: 53556 kB
CommitLimit: 2075720 kB
Committed_AS: 290860 kB
PageTables: 1968 kB
VmallocTotal: 114680 kB
VmallocUsed: 14940 kB
VmallocChunk: 96880 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 4096 kB
aubrey@linux:~/cvs/kernel/uClinux-dist> ./ma
Alloc 300 MB !
alloc successful
===============================================================
Aubrey <[email protected]> wrote:
>
> > 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.
Yup.
> 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.
The host has an MMU and hence is able to map discontiguous physical pages
into a virtually contiguous block. The blackfin doesn't have an MMU and
hence requires that 10MB's worth of physically contiguous pages be free.
Which is so hard to achieve after the system has been up for a while that
the kernel won't even attempt it.
Aubrey wrote:
> On 3/1/06, Andrew Morton <[email protected]> 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