Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The real realtime preemption end game

lwn.net

Post reply on HN
Print view View original

241–250 of 281 posts

Re: The real realtime preemption end game

#241

Post by snvzz »

_kb wrote: post #195
vacuity wrote: post #138

Earlier quoted context omitted.

For a modern example, there's seL4. I believe it does no dynamic memory allocation. It's also formally verified for various properties. (Arguably?) its biggest contribution to kernel design is the pervasive usage of capabilities to securely but flexibly export control to userspace.

And unfortunately had its funding dumped because it wasn’t shiny AI.

Its old source of funding. And it was much more complex[0] than that.

seL4 is now a healthy non-profit, seL4 foundation[1].

0. https://microkerneldude.org/2022/02/17/a-story-of-betrayal-c...

1. https://microkerneldude.org/2022/03/22/ts-in-2022-were-back/

Re: The real realtime preemption end game

#242

Post by snvzz »

fbdab103 wrote: post #62
Aaargh20318 wrote: post #27

What does this mean for the common user? Is this something you would only enable in very specific circumstances or can it also bring a more responsive system to the general public?

My understanding is that real-time makes a system slower . To be real-time, you have to put a time allocation on everything. Each operation is allowed X budget, and will not deviate. This means if the best-case operation is fast, but the worst case is slow, the system has to always assume worst case.

>real-time makes a system slower.

linux-rt's PREEMPT_RT has a negligible impact. It is there, but it is negligible. It does, however, enable a lot of use cases where Linux fails otherwise, such as pro audio.

In modern usage, it even helps reduce input jitter with videogames and enable lower latency videoconference.

I am hopeful most distributions will turn it on by default, as it benefits most users, and causes negligible impact on throughput-centric workloads.

Re: The real realtime preemption end game

#243

Post by formerly_proven »

bloak wrote: post #60
wholesomepotato wrote: post #24

Earlier quoted context omitted.

Features of modern CPUs don't really prevent them from real time usage, afaik. As long as something is bounded and can be reasoned about it can be used to build a real time system. You can always assume no cache hits and alikes, maximum load etc and as long as you can put a bound on the time it will take, you're good to go.

So the things that might prevent you are: 1. Suppliers have not given you sufficient information for you to be able to prove an upper bound on the time taken. (That must happen a lot.) 2. The system is so complicated that you are not totally confident of the correctness of your proof of the upper bound. 3. The only upper bound that can prove with reasonable confidence is so amazingly bad that you'd be better off with…

You're probably thinking about bus arbiters in 4.), which are generally fast but have no bounded settling time.

Re: The real realtime preemption end game

#244

Post by creshal »

dontlaugh wrote: post #240
creshal wrote: post #238

Earlier quoted context omitted.

> Millions of lines of kernel, all of which have to be made preemptable. ~90% of those are device drivers, which you'd still need with a microkernel if you want it to run or arbitrary hardware.

But crucially, drivers in a microkernel run in user space and are thus pre-emptible by default. Then the driver itself only has to worry about dealing with hardware timing when pre-empted.

Sure, but who's going to write the driver in the first place? Linux's "millions of lines of code" are a really underappreciated asset, there's tons of obscure hardware that is no longer supported by any other actively maintained OS.

Re: The real realtime preemption end game

#245

Post by josephg »

adastra22 wrote: post #209
vacuity wrote: post #204

Earlier quoted context omitted.

Yes, but I believe seL4 took it to the max. I may be wrong on that count, but I think seL4 is unique in that it leverages capabilities for pretty much everything except the scheduler. (There was work in that area, but it's incomplete.)

L4 was developed in the 90's. Operating Systems like Amoeba, which were fundamentally capability-based to a degree that even exceeds L4, were a hot research topic in the 80's. L4's contribution was speed. It was assumed that microkernels, and especially capability-based microkernels were fundamentally slower than monolithic kernels. This is why Linux (1991) is monolithic. Yet L4 (1994) was the fastest operating syste…

How did it achieve its speed? My understanding was that microkernel architectures were fundamentally slower than monolithic kernels because context switching is slower than function calls. How did L4 manage to be the fastest?

Re: The real realtime preemption end game

#246

Post by dontlaugh »

creshal wrote: post #244
dontlaugh wrote: post #240

Earlier quoted context omitted.

But crucially, drivers in a microkernel run in user space and are thus pre-emptible by default. Then the driver itself only has to worry about dealing with hardware timing when pre-empted.

Sure, but who's going to write the driver in the first place? Linux's "millions of lines of code" are a really underappreciated asset, there's tons of obscure hardware that is no longer supported by any other actively maintained OS.

I also don't see how we could transition to a microkernel, indeed.

Re: The real realtime preemption end game

#247

Post by yosefk »

SubjectToChange wrote: post #207
gigatexal wrote: post #160

Earlier quoted context omitted.

QNX is used in vehicle infotainment systems no? Where else? I'm not bothered by the kernel bloat. There's a lot of dev time being invested in Linux and while the desktop is not as much of a priority as say the server space a performant kernel on handhelds and other such devices and the dev work to get it there will benefit the desktop users like myself.

Railroads/Positive Train Control, emergency call centers, etc. QNX is used all over the place. If you want an even more impressive Microkernel RTOS, then Green Hills INTEGRITY is a great example. It's the RTOS behind the B-2, F-{16,22,35}, Boeing 787, Airbus A380, Sikorsky S-92, etc.

"Even more impressive" in what way? I haven't used INTEGRITY but used the Green Hills compiler and debugger extensively for years and they're easily the most buggy development tools I've ever had the misfortune to use. To me the "impressive" thing is their ability to lock safety critical software developers into using this garbage.

Re: The real realtime preemption end game

#248

Post by snvzz »

calvinmorrison wrote: post #18
binary132 wrote: post #13

Earlier quoted context omitted.

I get the sense that applications with true realtime requirements generally have hard enough requirements that they cannot allow even the remote possibility of failure. Think avionics, medical devices, automotive, military applications. If you really need realtime, then you really need it and "close enough" doesn't really exist. This is just my perception as an outsider though.

If you really need realtime, and you really actually need it, should you be using a system like Linux at all?

This is why the distinction between soft and hard realtime exists.

Linux-rt makes linux actually decent at soft realtime. PREEMPT_RT usually results on measured peak latency for realtime tasks (SCHED_RR/SCHED_FIFO) on the order of a few hundred usec.

Standard Linux lets latency go to tens of milliseconds, easily verifiable by running cyclictest from rt-tests for a few hours while using the computer. Needless to say, this is unacceptable for many user cases, including pro audio, videoconference and even gaming.

In contrast, AmigaOS's exec.library had no trouble yielding solid sub-millisecond behaviour in 1985, on a relatively slow 7MHz 68000.

No amount of patching Linux can give you hard realtime, as it is about hard guarantees, backed up by proofs built from formal verification, which Linux is excluded from due to its sheer size.

There's a few RTOSs that are formally verified, but I only know one that provides process isolation via the usual supervisor vs user CPU modes virtualization model: seL4.

Re: The real realtime preemption end game

#249

Post by matheusmoreira »

Animats wrote: post #130

QNX had this right decades ago. The microkernel has upper bounds on everything it does. There are only a few tens of thousands of lines of microkernel code. All the microkernel does is allocate memory, dispatch the CPU, and pass messages between processes. Everything else, including drivers and loggers, is in user space and can be preempted by higher priority threads. The QNX kernel doesn't do anything with strings.…

And yet it's getting done! It's very impressive work.

Re: The real realtime preemption end game

#250

Post by cduzz »

lmm wrote: post #222
cduzz wrote: post #200

Earlier quoted context omitted.

You're still on one side or another of the CAP triangle. In a network partition, you are either offline or your data is not consistent. If you're writing local to your system, you're losing data if there's a single device failure. https://en.wikipedia.org/wiki/CAP_theorem

CAP is irrelevant, consistency does not matter for logs.

Consistency is a synonym for "guaranteed", and means "written to 2 remote, reliable, append-only storage endpoints" (for any reasonable definition of reliability)

So -- a single system collecting a log event -- it is not reliable (guaranteed) if written just to some device on that system. Instances can be de-provisioned (and logs lost), filesystems or databases can be scrambled, badguys can encrypt your data, etc.

In this context, a "network partition" prevents consistency (data not written to reliable media) or prevents availability (won't accept new requests until their activity can be logged reliably).

If you define "reliably" differently, you may have a different interpretation of log consistency.

Post reply on HN