Quote of the week

[Posted October 14, 2015 by corbet]

Personally, I'd be happy to see RT-PREEMPT go in - there are certain use cases for it. I'd also like to see the NOHZ stuff go in as well. It should solve a set of problems for isolating RT tasks without sacrificing performance on the non-RT CPUs. And finally, I wouldn't mind putting a non-Linux RT kernel like Cobalt (oh the horrors) into mainline as well. Each of these approaches has their strengths and weaknesses. Linux is, after all, whatever we say it is - and it could easily have a small RT micro-kernel as part of the source base as well.

AFAIK the patent issues that plagued the dual-kernel approach are now behind us, so this might be a good area of investigation.

I've long felt that RT-PREEMPT was sucking the oxygen out of getting other, technically valid, approaches to RT with Linux into mainline.

— Tim Bird

to post comments

Quote of the week

Posted Oct 15, 2015 1:16 UTC (Thu) by karim (subscriber, #114) [Link] (2 responses)

FWIW, for having been one of the first proponents of real-time in Linux, I fully agree with Tim.

The ipipe vs. PREEMPT_RT debate that took place 10 years ago on the lkml was essentially resolved by the consensus being to focus on PREEMPT_RT. At the time I had congratulated Thomas for this -- having myself been on the other side of the debate. 10 years onwards, though, it seems pretty clear that the PREEMPT_RT approach is far more complicated than its most enthusiastic proponents would've hoped. In that regard, the ipipe patch, had it been accepted, would've given us hard-rt 10 years ago. But past-conditionals don't make us move forward.

Still, not having a mainline solution for this long has forced the market to find its own solutions. And as Tim states in his post, industry has chosen to sometimes use one approach and sometimes use the other. There is wisdom in this and the kernel may benefit of making both available. The code has been there for quite some time. It's been used in many real products. Also, merging one doesn't preclude merging the other. It's not unprecedented for the kernel to have multiple ways of doing a similar functionality, each catering for different crowds and use-cases. There's no reason that's not for the case for real-time as well.

Quote of the week

Posted Oct 15, 2015 2:16 UTC (Thu) by nevets (subscriber, #11875) [Link]

Actually, we work with the Xenomai folks. There's actually a benefit to having both a micro-kernel and PREEMPT_RT running together. You see. We really can "all just get along" (TM).

Quote of the week

Posted Oct 16, 2015 9:19 UTC (Fri) by arnout (subscriber, #94240) [Link]

> And as Tim states in his post, industry has chosen to sometimes use one approach and sometimes use the other. There is wisdom in this and the kernel may benefit of making both available.

It's a pity this didn't come two weeks earlier - I could have quoted you in my ELC-E presentation about Xenomai and PREEMPT-RT.

Quote of the week

Posted Oct 15, 2015 18:04 UTC (Thu) by einstein (subscriber, #2052) [Link]

I'd welcome any hard or soft RT solution so long as it is Linux - meaning that people actually want to run Linux, and their Linux applications, with RT properties. If some other kernel is substituted, say goodbye to running your favorite time-critical Linux app so enabled.

"Real" real time

Posted Oct 20, 2015 0:06 UTC (Tue) by vomlehn (guest, #45588) [Link]

I appreciate the work that the RT patch community has done over the years and, as someone who works in the embedded and occasionally real time world, I've seen the benefits it provides. And the more that's done, the better the kernel will be.

But, it is never going to provide the kind of speed you can get with a really minimal real time kernel. There are multiple companies offering this with virtualized kernels and they make a pretty good case. They are, however, generally not open source.

That's where Linux can step in. A real time kernel tightly integrated with Linux, or at least a standard interface between two kernels, with both being just as much open source as Linux is now would be great. Linux has been about support all sorts of functionality for all sorts of communities, this would simply be a continuation of that mindset.