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

251–260 of 281 posts

Re: The real realtime preemption end game

#251

Post by vacuity »

josephg wrote: post #245
adastra22 wrote: post #209

Earlier quoted context omitted.

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?

Two factors are the small working set (fit the code and data in cache) and heavily optimized IPC. The IPC in L4 kernels is "a context switch with benefits": in the best case, the arguments are placed in registers and the context is switched. Under real workloads, microkernels probably will be slower, but not by much.

Re: The real realtime preemption end game

#252

Post by naasking »

vacuity wrote: post #206
monocasa wrote: post #198

Earlier quoted context omitted.

The other L4s before it showed that caps are useful and can be implemented efficiently.

https://dl.acm.org/doi/pdf/10.1145/2517349.2522720 " We took a substantially different approach with seL4; its model for managing kernel memory is seL4’s main contribution to OS design. Motivated by the desire to reason about resource usage and isolation, we subject all kernel memory to authority conveyed by capabili- ties (except for the fixed amount used by the kernel to boot up, including its strictly bounded stack…

seL4 was heavily inspired by prior capability based operating systems like EROS (now CapROS) and Coyotos. Tying all storage to capabilities was core to those designs.

Re: The real realtime preemption end game

#253

Post by naasking »

vacuity wrote: post #220
mananaysiempre wrote: post #218

Earlier quoted context omitted.

IIRC the KeyKOS/EROS/CapROS tradition used capabilities for everything including the scheduler. Of course, pervasive persistence makes those systems somewhat esoteric (barring fresh builds, they never shut down or boot up, only go to sleep and wake up in new bodies; compare Smalltalk, etc.).

Guess I'm too ignorant. I need to read up on these. I did know about the persistence feature. I think it's not terrible but also not great, and systems should be designed for being shut down and apps being closed.

> I think it's not terrible but also not great, and systems should be designed for being shut down and apps being closed.

The problem with shutdowns and restarts is the secure bootstrapping problem. The boot process must be within the trusted computing base, so how do you minimize the chance of introducing vulnerabilities? With checkpointing, if you start in a secure state, you're guaranteed to have a secure state after a reboot. This is not the case with other any other form of reboot, particularly ones that are highly configurable and so easy for the user to introduce an insecure configuration.

In any case, many apps are now designed to restore their state on restart, so they are effectively checkpointing themselves, so there's clearly value to checkpointing. In systems with OS-provided checkpointing it's a central shared service and doesn't have to be replicated in every program. That's a significant reduction in overall system code that can go wrong.

Re: The real realtime preemption end game

#254

Post by naasking »

dontlaugh wrote: post #246
creshal wrote: post #244

Earlier quoted context omitted.

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.

The very first "hypervisors" were actually microkernels that ran Linux as a guest. This was done with Mach on PowerPC/Mac systems, and also the L4 microkernel. That's one way.

The only downside of course, is that you don't get the isolation benefits of the microkernel for anything depending on the Linux kernel process.

Re: The real realtime preemption end game

#255

Post by synergy20 »

froh wrote: post #154
synergy20 wrote: post #28

Earlier quoted context omitted.

no you don't, you use a true RTOS instead. linux RTOS is at microseconds granularity but it still can not 100% guarantee it, anything in cache nature (L2 cache, TLB miss) are hard for hard real time. a dual kernel with xenomai could improve it, but it is not widely used somehow, only used in industrial controls I think. linux RT is great for audio, multimedia etc as well, where real-time is crucial, but not a MUST.

> anything in cache nature (L2 cache, TLB miss) are hard for hard real time yup that's why you'd pin the memory and the core for the critical task. which, alas, will affect performance of the other cores and all other tasks. and whoosh there goes the BOM... which again as we both probably are familiar with leads to the SoC designs with a real time core microcontroller and a HPC microprocessor on the same package. whi…

that's indeed the trend, i.e. put a small RTOS core along with a normal CPU for non-real-time tasks, in the past it's done on two boards: one is a MCU another is a typical CPU, now it's one one, very important for where RTOS is a must, e.g. robotics.

How the CPU and MCU communicate is a good question to tackle, typically chip vendors provide some solutions, I think OpenAMP is for this.

Re: The real realtime preemption end game

#256

Post by loeg »

lopkeny12ko wrote: post #75
loeg wrote: post #4

Synchronous logging strikes again! We ran into this some at work with GLOG (Google's logging library), which can, e.g., block on disk IO if stdout is a file or whatever. GLOG was like, 90-99% of culprits when our service stalled for over 100ms.

I would posit that if your product's availability hinges on +/- 100ms, you are doing something deeply wrong, and it's not your logging library's fault. Users are not going to care if a button press takes 100 more ms to complete.

Our service is expected to respond to small reads at under 1ms at the 99th percentile. >100ms stalls (which can go into many seconds) are absolutely unacceptable.

Re: The real realtime preemption end game

#257

Post by vacuity »

naasking wrote: post #253
vacuity wrote: post #220

Earlier quoted context omitted.

Guess I'm too ignorant. I need to read up on these. I did know about the persistence feature. I think it's not terrible but also not great, and systems should be designed for being shut down and apps being closed.

> I think it's not terrible but also not great, and systems should be designed for being shut down and apps being closed. The problem with shutdowns and restarts is the secure bootstrapping problem. The boot process must be within the trusted computing base, so how do you minimize the chance of introducing vulnerabilities? With checkpointing, if you start in a secure state, you're guaranteed to have a secure state af…

It's fallacious to assume that the persistence model of the system can't enter an invalid state and thus cause issues similar to bootstrapping. The threat model also doesn't make sense to me: if an attacker can manipulate the boot process, I feel like they would be able to attack the overall system just fine. Also, there's the bandwidth usage, latency, and whatnot. I think persistence is a strictly less powerful, although certainly convenient, design for an OS.

Re: The real realtime preemption end game

#258

Post by snvzz »

tinix wrote: post #217
robocat wrote: post #171

Earlier quoted context omitted.

xrun definition: https://unix.stackexchange.com/questions/199498/what-are-xru... (I didn't know the term, trying to be helpful if others don't)

just a buffer under/overrun

it's cross-run aka xrun because these buffers are circular.

Depending on implementation, it will either pause or play the old sample where the new one isn't yet but should be.

Re: The real realtime preemption end game

#259

Post by snvzz »

eisbaw wrote: post #19

Great to hear. However even if Linux the kernel is real-time, likely the hardware won't be due to caches and internal magic CPU trickery. Big complex hardware is a no-no for true real-time. That's why AbsInt and WCET tools mainly has simple CPU architectures. 8051 will truly live forever. btw, Zephyr RTOS.

>8051 will truly live forever.

68000 is the true king of realtime.

Re: The real realtime preemption end game

#260

Post by snvzz »

dist-epoch wrote: post #74
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?

It could allow very low latency audio (1-2 ms). Not a huge thing, but nice for some audio people.

s/nice/needed/g
Post reply on HN