The world no longer needs RTOSes. Linux can do it all.
Or so it was suggested at the recent RTECC conference, where none other than renowned embedded Linux booster Jim Ready of MontaVista (now Cavium) gave a presentation suggesting that, at this point, there is really no need for anything but Linux.
While that seemed more extreme than I had been thinking, this coincided with some mulling I had been doing as to whether the role of RTOSes was changing. It provided a perfect opportunity to check in with a couple of RTOS guys to see if they agreed that their days were numbered. You might think you know their answers – yet you might be surprised.
Before we go there, however, let’s review the landscape to understand the context of this discussion. Multicore is becoming more prevalent in embedded applications, but, as in the case of multicore applications processors in smartphones, the cores are often managed as a group with a single OS (often Linux) operating in the symmetric multicore processing (SMP) model.
SMP means that, to the OS, all cores look alike and have access to the same resources. SMP OSes have scheduling capabilities that, to first order, allow any task to be scheduled on any core at the whim of the OS. There are some knobs that can be turned to impact this, but, for the most part, you end up treating the scheduler like some mysterious man behind the curtain who giveth tasks and taketh them away again using occult divinations to determine what goes where when. In other words, it’s opaque.
Lots of applications just can’t work that way, and there are a couple of reasons why. One is the classic requirement for hard real-time response, where you have to be able to prove deterministically that certain events can occur with hard, guaranteed deadlines. An inscrutable scheduler does not fit that description.
The other reason is one of efficiency and performance: when you’re trying to squeeze every last cycle out of a system, you want to take control of the timing yourself and have the scheduler back off. This is the case with packet-processing systems, where the hardcore “fast path” that has to handle the majority of “typical” packets can’t mess about with shifting duties from core to core; the modus operandi is, “Shut up and work.” Having a meddling OS that keeps interrupting to see if anything needs scheduling – when you’ve set things up specifically not to move about – or performing any number of other “services” that you’d rather do without simply wastes precious performance.
The solution to these situations is to operate in an asymmetric multicore processing (AMP) model. Here different cores can run different OSes. You might have a couple of cores operating together as SMP under one OS and then other cores running a smaller RTOS or even no OS at all (so-called bare-metal operation, often assisted with a slim executive for bare-minimum services).
This is the status quo. The new proposal is that Linux can now cover all of the use cases together. Rather than having more than one OS, you can have a single installation of Linux and then tune how each core operates. This is based on two principles:
- Linux can now perform as a real-time OS. Jim is quite passionate about this, displaying obvious frustration that this has been the case for 10 years, and yet still people dismiss the notion of real-time Linux.
- MontaVista’s relatively new Bare-Metal Engine (of which little information is available online) can now provide that thin layer of minimal services needed to support bare-metal applications.
This means that, for new applications, there’s pretty much no reason to go anywhere besides Linux.
I wanted to test this hypothesis with two fellows that have a stake in the race: John Carbone, CEO of Express Logic, and David Kleidermacher, CTO of Green Hills. Both companies provide RTOSes, among other things.
So let’s get the biggest surprise out of the way right away. When I posed the above proposition, I was expecting a hearty and outraged refutation. In fact, both agree that Linux has improved mightily and may, in fact, be able to operate in real-time applications that wouldn’t have been possible in the past.
So do they think that their own products are going away? Of course not. There’s nuance here that we need to tease out.
First of all, there’s real time, and then there’s hard real time. And then there’s “prove it” real time. There appears to be little doubt that Linux can handle some real-time applications. But it depends on the deadline and how hard it is. David referred to LTE operations in wireless base stations: they have to be able to handle a specified number of packets in a fixed time to avoid dropping calls. This can be hard to achieve with Linux.
But here’s the real clincher: for the most demanding applications, it’s not enough to prove empirically that you can meet the deadlines. You can run for weeks without failing, but if you can’t show a calculation that proves deterministically that you can always meet the deadline, it’s no good. And that’s the trouble with Linux: it’s so complex that it would be virtually impossible to do such a calculation. While both David and John believed that, anecdotally, Linux might work in some apps, they had never seen a calculation settling the question once and for all.
And even if you did settle the question, it would all change with the next update.
With respect to overhead, John maintains that, especially with small, cheap processors, you really need an RTOS that’s been purpose-built with a small footprint and low overhead. While the high-end Cavium chips can certainly support Linux, he suggests that the lowest-end devices would have a harder time of it. He personally hasn’t seen much uptake of the BME option.
David takes things further, painting a picture of a changing environment that looks like neither the old model nor Jim’s vision. With increasing demands for security and stability, characteristics de-prioritized in many embedded systems to date, he sees virtualization playing an increasing role. For instance, you might have a ten-line hypervisor thread that does nothing but watch Linux and restart it if it crashes.
This also fits the model that companies like ARM are touting with technologies like TrustZone, where you have a secure minimal trusted compartment with its own OS surrounded by fortress walls and with a separate OS for the plebeians where all manner of shenanigans might take place that can’t disturb the sacred relics protected behind ten feet of stone.
David could see, for example, a simple 100-line security agent that doesn’t operate under Linux and therefore lies beyond its grasp. Virtualization underlies this, compartmentalizing the zones and keeping them from mucking each other up.
So, while everyone gives due credit to the improvements made to Linux, there is no unanimity in hailing a new Linux-only embedded paradigm.
And that probably comes as no surprise.
Leave a Reply
You must be logged in to post a comment.