Hacker News Reader

Comment by lucb1e | Hacker News Reader

For more info on the second point: https://en.wikipedia.org/wiki/Linux_kernel#Preemption seems to have something to do with real-time operating systems, but I didn't dive into it.

Edit: Thanks for the downvotes without commenting what I should do differently next time?

View on HN

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.

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.

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.

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.

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.

Reply on news.ycombinator.com