"An RTOS (Real-time Operating System) will sacrifice performance to achieve determinism (low latencies). Several key features to an RT system usually come with a performance cost. A non RT system will perform 99% of the time faster than an RTOS. But all it takes is that one time to miss a deadline to make an RT system crash. An RTOS may be slightly slower, but it will not have those outliers that a normal desktop system would have."
"This is the largest performance improvement to hit the RT patch since the removal of the global PI lock. On my 4way box running 'hackbench 50' went from 18 seconds down to just under 5 seconds (4.8). Vanilla 2.6.24.7 on this same box runs at 3.9 secs. This is the first time that the RT patched kernel is less than a magnitude away from mainline running this hackbench test."
"I thought that one could place a printk anywhere without worrying. But it seems that it is not wise to place a printk where the runqueue lock is held."
"Currently in mainline the balancing of multiple RT threads is quite broken. That is to say that a high priority thread that is scheduled on a CPU with a higher priority thread, may need to unnecessarily wait while it can easily run on another CPU that's running a lower priority thread," began Steven Rostedt, describing his patchset to introduce improved real time task balancing. He explained:
"Balancing (or migrating) tasks in general is an art. Lots of considerations must be taken into account. Cache lines, NUMA and more. This is true with general processes which expect high through put and migration can be done in batch. But when it comes to RT tasks, we really need to put them off to a CPU that they can run on as soon as possible. Even if it means a bit of cache line flushing. Right now an RT task can wait several milliseconds before it gets scheduled to run. And perhaps even longer. The migration thread is not fast enough to take care of RT tasks."
Steven described his test cases and numerous issues he noticed with the current balancing code, noting, "to solve this issue, I've changed the RT task balancing from a passive method (migration thread) to an active method. This new method is to actively push or pull RT tasks when they are woken up or scheduled."
"This is a formal announcement of Lguest64," Steven Rostedt said in an email posted to the Linux Kernel mailing list. He explained:
"Most are aware of the little puppies (lguest32, or simply lguest, or in some circles "rustyvisor"). But this time the puppies ate a bit too much. No more lean and mean puppies, now we got big fat lazy ones. Running on the hardware that's too lazy to do full virtualization. Yes, lguest now runs on x86_64!"
Steven went on to caution that lguest64 is still a new code base, "lguest64 is still going through a bit of growth pains, but its getting better. It's to a point that we are not that afraid to bring it to the dog show." The list of items left to do include getting SMP working for both the host and the guest, matching Rusty Russel's lguest32 feature set, and greatly optimizing the performance of the code. Steven noted that the goal is to ultimately get the 64-bit version of lguest merged into the mainline kernel.
