Currently the Linux kernel disables preemption inside spinlocks and interrupt handlers, and these code sections are not necessarily carefully written to be short and constant-time, so you can in theory get in a situation where all cores are running spinlock or interrupt handler code from low priority threads for arbitrarily long times, preventing higher priority realtime threads to run (which in practice means that whatever hardware you are controlling will be uncontrolled, and thus your self-driving car, rocket, plane or industrial machine might be destroyed).

The PREEMPT_RT patch solves this by reimplementing all kernel spinlocks as mutexes with priority inheritance that are fully preemptible and all interrupt handlers as preemptable threads.

The result is that if you have a bunch of real-time process/thread that do not make system calls, it's guaranteed that in a bounded amount time the highest priority set will be running.

If you do however make system calls (or even if you cause page faults because you didn't call mlockall() and accessed non-mlocked memory), with the exception of some system calls that provide better guarantees, then you can still have kernel spinlock contention with other threads that may hold the same spinlock for an unbounded amount of time, so the system is more limited than dedicated real-time OSes that are careful about this.

About PREEMPT_RT merge prep: are we talking about the patchset that leads to ultra-low-latency audio-friendly kernels tagged -rt, like https://aur.archlinux.org/packages/linux-rt/ or https://aur.archlinux.org/packages/linux-rt-bfq/ ? If so, I use these for pro audio (for live dsp / effects under 5ms), and have a few questions:

- Will these kernels become obsolete/unnecessary with the merge?

- What about BFQ, is it going to be merged at the same time too?

- This patchset has been existing for a long time. What prevented an earlier merge?

- Is the merge already scheduled to happen for a specific kernel release, or "when it's ready"?

> Will these kernels become obsolete/unnecessary with the merge?

If it merges, sure. It's nice to see it may be getting close.

> What about BFQ, is it going to be merged at the same time too?

BFQ merged a couple of years ago.

> This patchset has been existing for a long time. What prevented an earlier merge?

It's been scary in the amount of things it touches and the amount of semantics it changes. It's a big change in mindset. Many drivers have been broken or simply unsupported at times on the preempt-rt branches.

More and more of the underlying infrastructure has made it in over the past couple years.

> Is the merge already scheduled to happen for a specific kernel release, or "when it's ready"?

Nope... the most we can say is it is "close".

Thanks.

> "BFQ merged a couple of years ago."

Okay, got it. My question was driven by confusion of what exactly was package https://aur.archlinux.org/packages/linux-rt-bfq/ . Reading now the wiki in GitHub ( https://github.com/sirlucjan/bfq-mq-lucjan/wiki ), it's clear:

> Development version of BFQ

> The development version of BFQ [...] differs from the production version in that:

> - it contains commits not available for that kernel version;

> - it contains a lot of consistency checks to detect possible malfunctions.

So, linux-rt-bfq is linux-rt, sprinkled with extra fixes to bfq unmerged yet to mainline.

It aims to turn Linux into a real-time OS. The preempty patchset aims to give faster response times but the main focus is to remove all unbounded latencies - for example, situations where the delay can vary depending on other factors.

It's not strictly true that the rt-patchset is meant to give faster response times. It provides bounded response times. You get a guarantee that some code can run within the time frame that you specify. That's not necessarily faster.

I was at a meeting with people that were doing signal processing in "embedded" environments. They said the patch slowed them down a lot. They got better performance and more determanism even, by pinning processes to cores using prior knowledge.

This would kill most use cases for QNX+POSIX.

You'll still need QNX if you want to run a full GUI Unix-like OS from a single floppy disk.

That hasn't been the case for several years now has it, since perhaps QNX v4? If not, you'll need a time machine as well.

http://toastytech.com/guis/qnxdemo.html

http://qnx.puslapiai.lt/qnxdemo/qnx_demo_disk.htm

Recent QNX has removed Photon and encourages the use of Qt instead which while can be made small, certainly does not fit in 1.44mb especially in 64bit

Yeah, the usual size for a minimal Qt with either QWidgets or Qt Quick / QML is about 15 MB.

Do people still have this requirement in 2020?

Usually such use cases require a certain level of certification and security that Linux doesn't offer.

Having preemption throughout the whole kernel helps with everything Low-Latency whether on desktop, mobile or server systems; it's not limited to the traditional real-time use case, although it might obviously help there as well to some extent.

It's essentially just applying these patches: https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt...

The above is for kernel 5.4, as the patchset for 5.5 doesn't exist at the time of this post.

After applying the patches, you'll want to run "make nconfig" or "make menuconfig" and search for CONFIG_PREEMPT_RT and enable it and you should be good to go. The only downside in my experience is Virtual Box doesn't work with the -rt kernel as of right now, so I can't use it as my daily driver. It is a my preferred kernel though for gaming and overall desktop use. I use a custom low-latency kernel when I'm not using the -rt and it's been working well for me.

I didn't (and can't, because you replied to me) downvote, but since the downvoters are not sharing their reason, I guess I'll share my thoughts on it: I think the "quite some people at HN just enjoy downvoting" is potentially offensive as well as an overgeneralization, and they probably don't like either or both.

Aaaand downvotes for this as well, so I guess that means this is not it?

It's because discussing downvotes is against the HN Guidelines[1]:

> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

Folks downvote comments about downvoting because it's boring to read, and to discourage others from doing it.

[1]: https://news.ycombinator.com/newsguidelines.html

Well, you're now discussing about "downvoting" and by that logic, you are now breaking the HN Guidelines.

Note that your original comment is not downvoted anymore. That's the best reason not to complain about downvotes; usually it will be reversed soon enough if the comment has merit.

Early downvotes can happen through accident or randomness; all it takes is one or two people to misread your comment, or mistakenly tap the down arrow. Or they might have a valid reason for disagreeing and are in the process of writing a comment putting a different point of view.

But getting offended and defensive and editing your comment to complain about it only makes the original comment worse, and leads to an off-topic subthread like this.

Sure, edit the comment if you need to, but try to make it clearer and more informative; that's what I do if I get an early downvote and realise the comment could have been better-worded.

The down votes were because you clearly didn't understand what preemption(or that this is really about it being a realtime flag) is or add much to the conversation(mentioning anything at all that might add something, like even a bad question, "I heard people using raspberry pis for embedded, would this help?"). The downvotes on the other guy are because asking for feedback on downvotes is discouraged.

To contribute, the PREEMPT_RT has been around as a set of patches(if not this specific one, then at least some version of making linux a realtime os.). If you need to know that something will run within a specified amount of time realtime matters.

EDIT: Don't use this and think it will help performance, generally it kills throughput.

You don't talk about fight club here. I don't know who was the smartass that decided that but here we are. Stupid rule but it's their place.

And adding "offensive" every other sentence [1] assumes (for me at least - for others not that much) that you are talking about us as crybabies being easily offended. I almost downvoted for positioning yourself as a purveyor of ethics with the implied assumption that everybody will agree with you.

But in general people around here indeed _are_ easily offended - see for example 'rzv' in this thread being downvoted for talking about this very problem. Depends of course on the thread and on the self-selected audience.

So - what can you learn from a downvote? For me is: don't debate here - HN it's not a platform suitable for debating ideas.

[1] not by _you_ - but in general

Random feedbackless downvoting is more and more being clearly abused to censor seemingly random and perfectly acceptable comments. The fact that talking about it is against the site guidelines only makes the problem worse. HN needs to deal with this.

PG seems to understand that a community censorship mechanism needs safeguards. From http://www.paulgraham.com/hackernews.html :

> I think it's important that a site that kills submissions provide a way for users to see what got killed if they want to. That keeps editors honest, and just as importantly, makes users confident they'd know if the editors stopped being honest. HN users can do this by flipping a switch called showdead in their profile.

How can editors be "kept honest" if a bunch of their minions can just downvote users for no reason and any complaining is forbidden?

it's not "minions." Way way way back in the early days of the board we actually discussed what downvotes should mean. Argument 1 was that a vote should only indicate whether or not you thought a comment contributed to the discussion- and not indicate agreement or disagreement. This gave an indicator with a single purpose. Argument 2 was that a vote could also be used to indicate disagreement. This made one indicator mean more than one thing. Some suggested a second vote- in order to keep the indicators clear on what they were reporting.

pg eventually came down on the side of Argument 2, so voting can be either "I disagree" or "you comment is not useful."

I do agree that adding a comment when downvoting is useful to the downvotee, but alas sometimes these come off as mean or supercilious and leave a bad tone in general, spoiling the conversation (or igniting a flame war).

More and more often recently, I find downvoted comments that I thought are all perfectly useful and reasonable to the discussion. I in fact thought the downvotes were neither "useful" nor "contributing to the discussion". I would rather like to downvote the downvoters to reduce their karma and their power to perform these downvotes, but the only mechanic I have on HN to express my preference is to re-upvote the comment, which is not in fact its original intended purpose.

Rather, I would like to ignore all downvotes made by particular downvoters because I believe their judgements are highly flawed, independent of the quality of the original comment that was downvoted.

https://abstrusegoose.com/527 is highly relevant.

Agreed. And great link. The “your” seals it.