The future of realtime Linux in doubt

Posted Jul 8, 2014 23:08 UTC (Tue) by tglx (subscriber, #31301)
In reply to: The future of realtime Linux in doubt by SEJeff
Parent article: The future of realtime Linux in doubt

> Linux makes a great soft realtime system, but isn't that awesome for hard realtime.

Well, that's why preempt-RT is there.

> VXworks is better at hard rt,

Unfortunately nobody is allowed to publish a fair and objective comparison of preempt-RT and vxworks. All you can get are the WindRiver marketing whitepapers...

> which is why it runs most of those types of systems

Sure, according to statistics provided by the most objective source on that matter

> (up for debate I 'spose)

Indeed.

Thanks,

tglx

The future of realtime Linux in doubt

Posted Jul 9, 2014 13:30 UTC (Wed) by bokr (guest, #58369) [Link] (1 responses)

Preemption has been about guaranteeing CPU availability for time-wise
more important work than what the(!) CPU was doing, with hardware interrupt
signals being the primary way to yank the CPU's chain, so to speak.

But if you can design a system where every critical waiting-to-preempt
thread already has its own CPU, and its response latency is that of
a smart spinlock, then I'd argue the idea of preemption changes its focus
-- presumably to prioritizing access to communication resources,
or guaranteeing dedicated ones, like fixed packet slots in synchronous
fast-enough streams (or dedicated parallel wire paths between things, if
serial packet slot multiplexing is not fast enough), and so on.

Reading about RT scheduling and CPU affinity etc. in TLPI it seems like
the pieces are there to enable developers to configure Linux to do most
anything, but getting the kernel to adapt various flavors of niceness
automatically to any arbitrary mix of apps thrown at it is probably tricky.

The future of realtime Linux in doubt

Posted Jul 9, 2014 20:14 UTC (Wed) by klossner (subscriber, #30046) [Link]

In the embedded world, it's impractical to devote a CPU core to each interrupt source. Besides the cost issue -- my current project budgets $14 for the SoC -- the legacy code base never envisioned running its threads concurrently. Trying to do so would expose countless new race conditions.