Linux can be used a real time operating system ( RTOS ) for thermostats, household appliance controllers, mobile telephones, industrial robots, spacecraft, industrial control and scientific research equipment.
Linux is not only a perfect platform for experimentation and characterization of real-time algorithms, you can also find real time in Linux today in the standard off-the-shelf 2.6 kernel. You can get soft real-time performance from the standard kernel or, with a little more work (kernel patch), you can build hard real-time applications.
This article explores some of the Linux architectures that support real-time characteristics and discusses what it really means to be a real-time architecture. Several solutions endow Linux with real-time capabilities, and in this article author examine the thin-kernel (or micro-kernel) approach, the nano-kernel approach, and the resource-kernel approach. Finally, author describe the real-time capabilities in the standard 2.6 kernel and show you how to enable and use them.
An experimental new design for Linux’s virtual memory system would turn a large amount of system RAM into a fast RAM disk with automatic sync to magnetic media. Most servers comes with 2-16 GB ram installed but not with a terabyte of installed memory (for 1TB+ ram go with IBM / Sun E25k server line). There is a new kernel patch called Ramback:
Ramback is a new virtual device with the ability to back a ramdisk by a real disk, obtaining the performance level of a ramdisk but with the data durability of a hard disk. To work this magic, ramback needs a little help from a UPS. In a typical test, ramback reduced a 25 second file operation to under one second including sync. Even greater gains are possible for seek-intensive applications. The difference between ramback and an ordinary ramdisk is: when the machine powers down the data does not vanish because it is continuously saved to backing store. When line power returns, the backing store repopulates the ramdisk while allowing application io to proceed concurrently. Once fully populated, a little green light winks on and file operations once again run at ramdisk speed.
However, this solution depends upon UPS:
If line power goes out while ramback is running, the UPS kicks in and a power management script switches the driver from writeback to writethrough mode. Ramback proceeds to save all remaining dirty data while forcing each new application write through to backing store immediately.
Yesterday, I wrote about a serious Linux kernel bug and fix. However, few readers like to know about patching running Linux kernel. Patching production kernel is a risky business. Following procedure will help you to fix the problem.
Step # 1: Make sure your product is affected
First find out if your product is affected by reported exploit. For example, vmsplice() but only affects RHEL 5.x but RHEL 4.x,3.x, and 2.1.x are not affected at all. You can always obtain this information by visiting vendors bug reporting system called bugzilla. Also make sure bug affects your architectures. For example, a bug may only affect 64 bit or 32 bit platform.
Step # 2: Apply patch
You better apply and test patch in a test environment. Please note that some vendors such as Redhat and Suse modifies or backports kernel. So it is good idea to apply patch to their kernel source code tree. Otherwise you can always grab and apply patch to latest kernel version.
Step # 3: How do I apply kernel patch?
These instructions require having the skills of a sysadmin. Personally, I avoid recompiling any kernel unless absolutely necessary. Most our production boxes (over 1400+) are powered by mix of RHEL 4 and 5. Wrong kernel option can disable hardware or may not boot system at all. If you don’t understand the internal kernel dependencies don’t try this on a production box.
Change directory to your kernel source code:
# cd linux-2.6.xx.yy
Download and save patch file as fix.vmsplice.exploit.patch:
# cat fix.vmsplice.exploit.patch
@@ -1234,7 +1234,7 @@ static int get_iovec_page_array(const struct iovec __user *iov,
error = -EFAULT;
- if (unlikely(!base))
+ if (!access_ok(VERIFY_READ, base, len))
Now apply patch using patch command, enter:
# patch < fix.vmsplice.exploit.patch -p1
Now recompile and install Linux kernel.
I hope this quick and dirty guide will save someones time. On a related note Erek has unofficial patched RPMs for CentOS / RHEL distros.