Hi, I am with the client Steve is working for.
On Apr 12, 2013, at 9:00 AM, Lennart Sorensen <lsore...@csclub.uwaterloo.ca> wrote: > On Fri, Apr 12, 2013 at 07:34:19AM -0700, Steve deRosier wrote: >> Hi all, >> >> Every time our application mallocs any small number of bytes (<8k), >> the device seems to malloc an entire page (8k). Does anyone know why >> this happens, and how I can fix it? > > Imagine the amount of fragmentation you would get if different > applications could all be given allocations from one page. That would > be a mess. Now the libc could be smart and maintain a heap for you that > it does small allocations from and doesn't give back when you do a free. > I think glibc does that, but I have never checked how uClibc does it, > given I have never done such allocationsin uClinux code. > > Certainly looking at the code, there is malloc_from_heap used by malloc, > so it sure looks like uClibc does the sensible thing. In that case small > allocations shouldn't be a problem, unless you allocate a bunch, keep > a few and free the rest, repeat a lot, causing enourmous fragmentation > of the heap. If that is the case, perhaps your algorithm needs a major > rethink. > >> Full details: >> >> This same application ran fine on a Linux 2.4.x (uClinux) platform, >> but due to various reasons we've had to upgrade the platform to 3.3.0 >> (still uClinux). Coldfire mcf5235, 4 MB flash, 32 MB RAM. We're using >> uClibc. >> >> At the time we start the application, there is ~20 MB free, it runs >> for 30+ seconds and then the OOM killer kills it. On the 2.4.x >> platform, it has a high-water-mark of about 2 MB, and runs in the >> steady-state at about 1.5 MB. >> >> After much investigation (eventually culminating in a debug version of >> malloc printing each allocation request, then sleeping for 2 seconds, >> where I cat /proc/meminfo), we finally noticed that each allocation, >> typically 10-40 bytes, reduces meminfos's MemFree by 8k. >> >> Other than the underlying kernel and wholesale upgrade of the uClinux >> base, nothing has really changed on the system. We're still selecting >> the same packages and configuration as near as possible. > > So it used to work and now it doesn't? > > Might be worth listing the version of uClibc and other bits you are using, > in addition to the kernel version. The version of uClinux we are currently running is from the tar ball uClinux-dist-20070130.tar.gz Linux version 2.4.32-uc0 Using power of 2 allocator Previously we were using a 2003 distribution of uClinux on the M5282 with the same code. -- Anthony Best _______________________________________________ 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
