On Fri, Apr 12, 2013 at 8: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
Well, yes, I do actually understand memory allocation in general and I do get that it would be an issue for the kernel to give different applications allocations from a single page. That's not what I'm concerned about. It's that every single allocation, no matter how many bytes results in a full page being allocated by the kernel. By my way of thinking, the C library should be managing the heap and only getting a new page when it needs one, not a single page each time. Very importantly, it all worked as expected on the earlier uClinux platform but isn't working correctly now. > 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. No, there shouldn't be lots of fragmentation in the way the algo works. It does a bunch of allocations near the beginning of the program to load up various working data sets. It does do some frees, but in generally the allocations and frees related to those are in chunks and ordered correctly to avoid fragmentation Profiling it on a normal desktop linux shows pretty good behavior with less than 1% heap fragmentation I happen to agree that the program in question needs a major rethink, but that's neither germane to the question nor within the scope of my contract with the client. > >> 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. > > So it used to work and now it doesn't? > Yup. > Might be worth listing the version of uClibc and other bits you are using, > in addition to the kernel version. Linux 3.3.0 on a Coldfire 5235 platform. uClinux was from the 20120401 distribution. From digging into the uClibc directory, the Changelog states: "0.9.27 12 January 2005". Which matches the old version. So, either there's been and upgrade of uClibc and the changelog is abandoned, or uClinux hasn't updated that package in a little while. Since I can't confirm that our uClibc config is the same between the old and new platforms, I'll assume our config of uClibc is different. 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
