Anna, >> Subject: Re: [uClinux-dev] ucLinux and XIP memory savings >> >> Hi Larry, >> >> Thanks for your response. >> >>> Subject: Re: [uClinux-dev] ucLinux and XIP memory savings >>> >>> Anna, >>> >>> It is a national holiday in the US, so I am out of the office until >>> Monday when I will be able to send you more details. >>> >>> I tried to use a Lantronix EDS2100 for an RS-232 data-logging >>> application with remote access. That box has an M68K ColdFire >>> processor, 8MB RAM, 8 MB flash. I used XIP and any other technique I >>> could find to increase RAM. The biggest headache was the Linux 2.6 >>> power-of-2 buddy system memory allocator. I guess in the 2.4 kernel, >>> there was a boxcar memory allocator. That would have been better for >>> such a small memory system. I had to resort to fixing GCC to try to >>> catch stack overflow problems in standard apps (NTP, for time -- no >>> RTC). But, I ran out of time to get the system to run reliably -- it >>> kept locking up because of memory allocation failures due to the >>> power- >>> of-2 memory allocation scheme. >> >> Is this really still true? I had read somewhere that it is possible to >> replace the standard kernel memory allocator under ucLinux with one >> that is better suited to embedded systems, e.g. a block-based memory >> pool type allocator. I cannot find the reference anymore now though. > > Actually I have just found that you are right and this was just the case for > Linux 2.4 which is completely irrelevant now :-( > > However, the power-of-2 memory allocation is a general problem for ucLinux > which is independent of XIP, isn't it?
Yes. There was a non-power-of-2 user memory allocator in Linux 2.4 (a uClinux project?). That was never ported to 2.6 or later. When I looked at the code, I came to the conclusion that too many places in the kernel rely on the power-of-2 allocations. I could be wrong, and something like a Fibonacci-based buddy memory allocator might work, as long as the smallest memory allocation unit is at least the page size. It is an interesting academic exercise, made a bit irrelevant by the cheap ARM SoCs I've started using. I don't have enough lifetimes to pursue all the things that interest me. :) > XIP does not make this any worse, does it? I'd say it should be more the > opposite as by using XIP we use less RAM in general and therefore memory > fragmentation hopefully has a little less impact. This was my result. At work I have my notes for the development effort on the Lantronix EDS2100. I employed every technique I could find to free RAM for use by the programs I needed for my application. > Anna 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
