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. -- Len Sorensen _______________________________________________ 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
