Hi Greg,
> What you are seeing though is a classic case of memory fragmentation. Thats true. If I spam a lot of 'ls' with other commands between, it eventually works. (I guess at some point a memory chunk of 1024k becomes available). I've tried to rebuild the kernel using as memory allocator SLOB and SLUB, but the result seems to be the same as using SLAB. > I would dig into the busybox ls code. Wanting to allocate a block of > 512k in a single chunk seems a bit crazy. I've tried with standalone 'ls' and the result is the same. It also fails wanting to allocate exacly 528384 (always the same value and only when ls'ing NFS mounts). (the mem alloc value is actually pretty rounded 512k + 4k) Could it be related to NFS kernel code? Don't know if it's relevant, but I'm using latest kernel sources from your git, gcc-4.7.2, running kernel from flash (XIP) and user binaries compiled with -msep-data (running from flash also). By the way, like Larry pointed out, is there a way to compile user binaries with shared flat libraries? Long time ago I've tried to enable UCLIBC_FORMAT_SHARED_FLAT in uClibc config, but then it was failing building (don't remember where/why it fails). Thanks, Luis On Tue, Oct 30, 2012 at 12:33 AM, Greg Ungerer <g...@snapgear.com> wrote: > Hi Luis, > > > On 30/10/12 05:38, Luis Alves wrote: >> >> Thanks for the explanation Larry. >> >> Meanwhile I've read some stuff about non-MMU memory alocation (I had >> the wrong idea of how memory was allocated). >> I guess my system ram is not that much (only 8Mb)... > > > What you are seeing though is a classic case of memory fragmentation. > You have eneough free RAM in total, but not enough in s ingle > contiguous block. On a paged MMU system this is not a problem, pages > can be mapped so you see a contiguous block the size you want. You > can't do that without no MMU and paging. > > > >> How would shared libs solve the problem? >> The problem is allocating memory for 'ls' data and not 'ls' itself. Is >> this correct? > > > I would dig into the busybox ls code. Wanting to allocate a block of > 512k in a single chunk seems a bit crazy. > > Regards > Greg > > > >> On Mon, Oct 29, 2012 at 5:49 PM, Larry Baker <ba...@usgs.gov> wrote: >>> >>> Luis, >>> >>> On 29 Oct 2012, at 8:32 AM, Luis Alves wrote: >>> >>> DMA: 36*4kB 30*8kB 29*16kB 21*32kB 6*64kB 7*128kB 4*256kB 3*512kB >>> 0*1024kB 0*2048kB 0*4096kB = 5360kB >>> >>> >>> The largest block of memory your system has available is 524288 >>> (512*1024). >>> >>> Allocation of length 528384 from process 94 (ls) failed >>> >>> >>> The requested size is larger than that, so uClinux tries to allocate the >>> next larger block size (1024K). There are none available. >>> >>> Any sugestion? >>> >>> >>> I do not know what determines how much memory ls allocates. >>> >>> I have similar memory allocation failures on my system. It does not >>> appear >>> to use a shared uclibc. I do not know (yet) how to enable building a >>> shared >>> uclibc or how to change the builds to use it. If the instructions are >>> straightforward, I would like to hear from someone. >>> >>> Regards, >>> Luis >>> _______________________________________________ >>> uClinux-dev mailing list >>> uClinux-dev@uclinux.org >>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> This message was resent by uclinux-dev@uclinux.org >>> To unsubscribe see: >>> http://mailman.uclinux.org/mailman/options/uclinux-dev >>> >>> >>> Larry Baker >>> US Geological Survey >>> 650-329-5608 >>> ba...@usgs.gov >> >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev@uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev@uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> >> >> > > > -- > ------------------------------------------------------------------------ > Greg Ungerer -- Principal Engineer EMAIL: g...@snapgear.com > SnapGear Group, McAfee PHONE: +61 7 3435 2888 > 8 Gardner Close FAX: +61 7 3217 5323 > Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
