On Fri, Apr 12, 2013 at 9:27 AM, Anthony Best <anthonyb...@bestanthony.com> wrote: > 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. >
Hi guys. Looks like we figured out what was going on. uClibc has two different malloc implementations for our platform. The simple malloc, the default, which we were using, simply goes out and grabs a chunk of ram via a mmap operation when you malloc anything. The standard malloc, manages the heap and only mmaps new ram when it runs out. Seems the old 2.4.3x version of Linux we were using managed mmap allocations via power-of-two buckets, giving the smallest bucket for each request. I don't know if that was standard back then for our platform or if that was something that they added for the product. The upgraded Linux 3.3 allocator simply gives an 8k page on each mmap request. So, combining the change to the 8k page allocation with using the simple malloc from uClibc and no matter the size of ram we requested, we would allocate the full 8k page for it. So a 16-byte request resulted in an 8192 byte allocation. Hence, OOM in about 3 seconds. The fix was to change uClibc to using the full version of malloc. Now it allocated properly and only consumed new 8k pages when it needed them. I don't know why I had trouble getting that to build, after a few config file tweaks and some make cleans, I got it to build. Easy to figure how how to solve the problem once I discovered the actual underlying behavior, but the inital problem had me scratching my head for a week or so before I could understand where the problem even was. Thanks for your help. I thought the list would appreciate the fix info incase someone else searched for an answer. Thanks, - Steve _______________________________________________ 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
