Jamie Lokier wrote:
Yes, i some instances it is necessary. I worked on an avionics platform
that used 4K page sizes, so it was constantly paging in and out memory
for execution. The interesting thing was i also used a non-MMU OS on
the same processor PPC750 and noted the non MMU OS executed much faster
and did a lot more.
I agree, the non-MMU version can be faster.
It shouldn't be _much_ faster, unless the hardware is exceptionally
poor design, or the OS just doesn't match the hardware very well.
I'm sure you've rad the paper sited and noted it was quite substantial.
Given the point about memory fragmentation is an issue. I contend that
it is primarily a large (sometimes medium) scale embedded systems issue.
And in systems using Java and C++ new/delete constantly.
For headless systems and ones semi-stagnant in memory
allocation/reallocation an MMU-less system has many advantages.
If on the other hand some form of memory garbage collection is necessary
then an MMU based OS fits the bill.
I have to say I found the opposite. My system doesn't have a VM or
garbage collector, there's no Java and only a tiny bit of C++, and all
the applications are quite stable w.r.t. memory allocation, doing only
a little every half minute or so.
(Ironically, some VMs are _better_ for no-MMU than not using a VM.
Those would be fragmentation-aware VMs that always allocate data
structures no larger than 1 page, and use indirection to split arrays.)
However, what they also do is run an "ssh" command every 30 seconds to
report home. That's enough to start the fragmentation problems.
This is in effect a new and delete every 30sec. It may not be Java or
C++ code that requires the garbage collection. But, causing the system
to act in object new/delete fashion has the same effect.
Any way to keep the ssh session open constantly?
There real trigger is the kernel's file handling. My system streams
files from a local disk. The kernel is quite unstable in it's file
cache management on no-MMU systems. Either it creates the worst case
for fragmentation (page_alloc.c) or it allocates so slowly and
interacts poorly with cache reclamation that it severely reduces
performance (page_alloc2.c), losing about 40% CPU just to the kernel's
memory management.
'local disk' implies to me that it is a large scale system. disk
caching is in effect a file system new/delete mechanism as well. ? is
it a local ram disk? If yes, do you force a sync on the filesystem
periodically?
Also is the memory in the file system getting fragmented? If yes, is it
possible to mount/unmount (possibly pseudo reformat as well) to fragment.
Unfortunately, my hardware doesn't have an MMU. Otherwise I would
definitely use it - the slower context switches would be hugely
outweighed by the speedup in kernel memory allocation, and being able
to use all the RAM, and disk caching that works, would be a bonus.
(I didn't know this when I started the project. I thought having no
MMU wouldn't be much of a problem. I guess it is still largely a
software problem, but a tough one that's a lot of work to solve.)
Can you replace the processor with an MMU variant? Sound's like you
need on based on the system usage
bob
--
*Robert Warner*
*Senior Embedded Systems Development Engineer*
*Kutta** Technologies*
Mobile: 734-355-3547
Office: 602.896.1976, Ext.242
Fax: 602.896.1007
[EMAIL PROTECTED]
www.kuttatech.com <http://www.kuttatech.com/>
Kutta Tech <http://www.kuttatech.com>
_______________________________________________
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
