 be looked at as running an RTOS as a (high priority, 100% active) User Space application. Developed either custom or as a general-market product, several of "micro kernel" environ- ments exist today, either as standalone development environments (example³) or as part of commercially available LTE/5G Layer-2 stack where the stack and the os are effectively com- bined into a single image. Combined, these three capabilities allow full "ownership" over CPU resources to a defined application, whilst continuing operation in an Symmetric Multi Processing (SMP) Linux os and benefiting from its features, including development environment, trace/log capabilities and other os services. Containerization (Docker) and Virtualization (KVM) can still be supported, including "nested" PREEMPT_RT operation, but typically with perfor- mance impact. It is important to understand which applications benefit from virtualization (typically, higher-level applications) and which ones are better suited for nonvirtualized deployment (typically, applications that have performance criteria that do not allow for scal- ing benefits in virtualization). The second and last strategies (use Linux with preemption capabilities and build a cus- tom application scheduler on top) are typically preferred by application stack vendors to pro- mote software portability across platforms given that they rely only in limited fashion on the os infrastructure features. To support improved preemption performance (quantified as shown in Fig. 5-2), the Linux CONFIG_PREEMPT_RT patch set is applied. This patch allows nearly all the kernel to Total Latency = Interrupt + ISR + Scheduler Hardware Realtime Task Operating Interrupt Handler Linux Scheduler System Hardware HW IRQ IRQ Service Scheduler Latency Latency Scheduler Delay Latency FIGURE 5-2 Operating system (OS) latency for interrupt handling. Chapter 5 System software be preempted, except for a few very small regions of code ("raw_spinlock critical regions"). This is done by replacing most kernel spinlocks with 