Linux Kernel 2.6: the Future of Embedded Computing, Part I

With the release of the 2.6 kernel, Linux's position in the embedded world has been cemented.

The embedded computing universe includes computers of all sizes, from tiny portable devices--such as wristwatch cameras--to systems having thousands of nodes distributed worldwide, as is the case with telecommunications switches. Embedded systems can be simple enough to require only small microcontrollers, or they may require massive parallel processors with prodigious amounts of memory and computing power. PDAs, microwaves, mobile phones and the like are a few typical examples.

With the release of kernel 2.6, Linux now poses serious competition to major RTOS vendors, such as VxWorks and WinCE, in the embedded market space. Linux 2.6 introduces many new features that make it an excellent operating system for embedded computing. Among these new features are enhanced real-time performance, easier porting to new computers, support for large memory models, support for microcontrollers and an improved I/O system. In this two-part article, we look at the improvements in the 2.6 kernel that have empowered it to make a foray into the demanding world of embedded computing.

Characteristics of Embedded Systems

For the uninitiated, embedded systems often need to meet timing constraints reliably. This is the most important criterion of an embedded system. Thus, a job executed after its scheduled deadline is as good as--or as bad as--a job executed incorrectly. In addition, embedded systems have access to far fewer resources than does a normal PC. They have to squeeze maximum value out of whatever is available. Often, a price difference of as little as $2 or $3 can make or break a consumer device produced on a large scale, such as wrist-watches.

Some real-world applications require the OS to be as reliable as possible, because the application is a part of a mission-critical operation. The OS should perform reliably and efficiently, if possible, under the cases of extreme load. If a crash occurs in one part of the module, it should not effect other parts of the system. Furthermore, recovery from crashes should be graceful. This more or less holds true for other non-critical embedded applications as well.

How Linux 2.6 Satisfies the Requirements

Having seen the requirements of a general embedded system, we now look at how well the Linux 2.6 kernel can satisfy these requirements. As mentioned earlier, embedded systems have stringent timing requirements. Although Linux 2.6 is not yet a true real-time operating system, it does contain improvements that make it a worthier platform than previous kernels when responsiveness is desirable. Three significant improvements are preemption points in the kernel, an efficient scheduler and improved synchronization.

Kernel Preemption

As with most general-purpose operating systems, Linux always has forbidden the process scheduler from running when a process is executing in a system call. Therefore, once a task is in a system call, that task controls the processor until the system call returns, no matter how long that might take. As of kernel 2.6, the kernel is preemptible. A kernel task now can be preempted, so that some important user application can continue to run. In Linux 2.6, kernel code has been laced with preemption points, instructions that allow the scheduler to run and possibly block the current process so as to schedule a higher priority process. Linux 2.6 avoids unreasonable delays in system calls by periodically testing a preemption point. During these tests, the calling process may block and let another process run. Thus, under Linux 2.6, the kernel now can be interrupted mid-task, so other applications can continue to run even when something low-level and complicated is going on in the background.

Embedded software often has to meet deadlines that renders it incompatible with virtual memory demand paging, in which slow handling of page faults would ruin responsiveness. To eliminate this problem, the 2.6 kernel can be built with no virtual memory system. Of course, it then becomes the software designer's responsibility to ensure enough real memory always is available to get the job done.

An Efficient Scheduler

The process scheduler has been rewritten in the 2.6 kernel to eliminate the slow algorithms of previous versions. Formerly, in order to decide which task should run next, the scheduler had to look at each ready task and make a computation to determine that task's relative importance. After all computations were made, the task with the highest score would be chosen. Because the time required for this algorithm varied with the number of tasks, complex multitasking applications suffered from slow scheduling.

The scheduler in Linux 2.6 no longer scans all tasks every time. Instead, when a task becomes ready to run, it is sorted into position on a queue, called the current queue. Then, when the scheduler runs, it chooses the task at the most favorable position in the queue. As a result, scheduling is done in a constant amount of time. When the task is running, it is given a time slice, or a period of time in which it may use the processor, before it has to give way to another thread. When its time slice has expired, the task is moved to another queue, called the expired queue. The task is sorted into this expired queue according to its priority. This new procedure is substantially faster than the old one, and it works equally as well whether there are many tasks or only a few in queue. This new scheduler is called the O(1) scheduler.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

When the kernel changes, so does GLIBC & so much more.

Manish Kochar's picture

SafeSquid suffered from ugly and irritating crashes, or more appropriately - Segfaults.
With version SafeSquid 4.1.1 we have a remarkable difference, in performance.
We just had to throw away our efforts to remain complaint to older kernels, and force it to use NPTL, and the newer GLIBC, and the results are simply fantastic.

I compliment Aseem for this article, and specially the paragraph on "Improved Threading Model and Support for NPTL"

I don't where Aseem picked that comment "LinuxThreads is Brain-dead", but I can only agree that it is, and was driving us into our coffins too!

Re: Linux Kernel 2.6: the Future of Embedded Computing, Part I

Anonymous's picture

The article says "Although Linux 2.6 is not yet a true real-time operating system,[...] " and that's why the mainstream Linux kernels have a long way to go before they can be used in deeply embedded devices rather than high-end stuff like PDAs.

And then there's the memory footprint. I don't think vxWorks, eCos, RTEMS, Nucleus etc. have that much to worry about for a while yet.

Though Real-Time features are

ryotson's picture

Though Real-Time features are inserted into the kernel, the Linux as a whole is not real-time. With support for pre-emption points and new scheduler, soft real-time performance can be achieved.
Efforts were made and were also successful in deeply embeddeding the Linux. Now with the support for completely removing the VFS from Linux, we can created much compact kernel.

-- ryotson

No way

Anonymous's picture

No way. Read this, then tell me again "Linux is the future of embedded computing". It's very far from that!

Re: No way

Anonymous's picture

"However, they do not have knowledge or experience when it comes to developing or supporting tools."

Well, this phrase above fairly show us who have written that doesnt know what is saying.


Re: No way

Anonymous's picture

Arrey Asmya,
u must counter the charges this guy has presented...only then will it be a fair reading..

Re: No way

Anonymous's picture

The article is full of statements that have absolutely no data to back them up. Whilst I have never had the opportunity to code for an embedded platform, I would not base any kind of decision on an article like that. My first opinion when reading that article was that it was FUD from some company that develops tools for another embedded platform

Re: No way

Anonymous's picture

Be sure to read Kevin Dankwardt's rebuttal, sent as an open letter to the EE Times.

You may also wish to check the talkbacks posted here.


Pure FUD.

Anonymous's picture

I'm a professional commercial embedded systems developer, and there's no way I'm -NOT- going to use Linux in my projects from now on. The tools support is in fact -better- than from commercial vendors, in that i have full source for everything, the build systems available (gentoo/rock/oe) are all fully open and well-designed for the linux-kernel-hacker problems usually faced, and ... well ... the products will speak for themselves.

any 'professional' who tells you they can't use linux in their embedded product is either a) lying to you, or b) grossly incompetent.

linux is the easiest and most accessible embedded-system environment to start using!! no $15,000 'license fees' to pay before you can start building system images!!!

Re: Linux Kernel 2.6: the Future of Embedded Computing, Part I

Anonymous's picture

And the fact that Linux 2.6 integrates support for many more
hardware platforms and more I/O hardware doesn't matter at all?
I'm surprised!

For example, significant chunks of the ARM trees are now
merged, with more on the way. There's also lots of
support for some of the less mainstream I/O hardware that's
used in embedded systems ... like I2C (no longer separate),
USB Devices (the "gadget" API, contrasting to the host
side API), IPMI, and more.

In 2.4 kernels, support for hardware used on embedded
boards was a lot harder to find, unless it was basically a
cut-down PC (PC104 etc). But in 2.6, more of that is
part of the package.
That means a lot less work for anyone who wants to be
running Linux on their not-so-mainstream hardware.

Would you like tools with that?

Anonymous's picture

It's worth mentioning that
shows how to conveniently build and test a gcc and glibc
to go with the embedded Linux of your choice...