The Neuros and Open Source: Linux v RTOS
From The Neuros Technology Wiki
Advantages of Linux over other embedded OS
- network performance
- selection of open source solutions
- open source developer support tools
Discussion of Issues
"The Linux boot time depends primarily on how many device drivers you have to initialize. There are a few little tricks to make it boot faster -- for example, hard-coding the BogoMIPS calculation. With a little tuning, it is not difficult to get Linux to boot in 3-5 seconds.
Most people also cheat in the following way: You put up a splash welcome screen in the boot loader BEFORE you start Linux. This gives the instant-on feedback. The intro splash screen is replaced with the operational screen in 3-5 seconds.
So, in general, the handheld boot time is good and can be improved if you really need (I've heard people claiming 500Ms boot times). It is not like the poor desktop machine that is loaded down with dozens of services that it has to start.
Are you familiar with: http://www.selenic.com/tiny/ ? They have packages of patches who want to make Linux very tiny and to boot very fast. I've never really used any of these."
"DM270+Linux is really a very good platform. The only technical thing that concerns me is the uClinux part. Without an MMU, the page cache usage causes memory fragmentation. After a few seconds, you can get hiccups in video or audio becuase uClinux has to take some drastic measures to recover contiguous memory. This is the toughest obstacle to getting solid performance from DM270+Linux.
If your operating system -- any operating system -- is using more than a small percentage of your processing bandwidth then something is wrong. The OS is responsible for good response latency but does not have a real role in raw performance (since most of the time the OS is just waiting for the next event)."
"The lack of MMU is certainly something of a weakness, but audio and video do not need to hiccup because of it. I have seen many systems without an MMU where the memory needed for multimedia buffers is allocated statically outside Linux. The necessary buffers are then allocated and freed from this otherwise un-managed pool that never pages out and never fragments. Of course, Linux and apps under Linux will never have a chance of using that memory even if multimedia services are not running.
I think that Igenient, Ittiam and Ateme use this mechanism with their non-MMU designs. I wouldn't be surprised if they did something like it even with MMU-based designs as well."
"They don't need to hiccup if you carefully analyze and design the system. But most people get surprised by uClinux memory usage.
The major reason for memory fragmentation is not memory allocated by the applications, but memory allocated by the kernel for the page cache. The default kernel behavior is to keep a copy everything you read from and write to the disk in memory in the page cache. In a streaming application, memory gets fragmented very quickly, not from the multimedia buffers, but from the page cache.
So the system operates with memory fully allocated all of the time, when something needs to allocate more memory, it is usually pretty easy to free some pages and get the needed memory. But as the fragmentation gets worse, the time to recover contiguous memory can get very large and hence the hiccups.
The are some hacks to get around this use of page cache. There are some implementations of O_DIRECT (no page cache) and O_STREAMING (don't keep pages in cache very long). But I don't think any of these are available in current kernel.
Linux is not good for managing large memory blocks so big memory regions that you need are best handled outside of Linux."