Re: ucLinux and XIP memory savings

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
[email protected]

_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev