PREEMPT_RT

  • Long-term project lead by Linux kernel developers Ingo Molnar, Thomas Gleixner and Steven Rostedt
  • The goal is to gradually improve the Linux kernel regarding real-time requirements and to get these improvements merged into the mainline kernel
    • PREEMPT_RT development works very closely with the mainline development
  • Many of the improvements designed, developed and debugged inside PREEMPT_RT over the years are now part of the mainline Linux kernel
    • The project is a long-term branch of the Linux kernel that ultimately should disappear as everything will have been merged

Improvements in the mainline kernel

From the PREEMPT_RT project

  • Since the beginning of 2.6
    • O(1) scheduler
    • Kernel preemption
    • Better POSIX real-time API support
  • Since 2.6.18
    • Priority inheritance support for mutexes
  • Since 2.6.21
    • High-resolution timers
  • Since 2.6.30
    • Threaded interrupts
  • Since 2.6.33
    • Spinlock annotations

New preemption options in Linux 2.6

1st option: no forced preemption CONFIG_PREEMPT_NONE Kernel code (interrupts, exceptions, system calls) never preempted. Default behavior in standard kernels.

  • Best for systems making intense computations, on which overall throughput is key.
  • Best to reduce task switching to maximize CPU and cache usage (by reducing context switching).
  • Still benefits from some Linux 2.6 improvements: O(1) scheduler, increased multiprocessor safety (work on RT preemption was useful to identify hard to find SMP bugs).
  • Can also benefit from a lower timer frequency (100 Hz instead of 250 or 1000).

2nd option: voluntary kernel preemption CONFIG_PREEMPT_VOLUNTARY Kernel code can preempt itself

  • Typically for desktop systems, for quicker application reaction to user input.
  • Adds explicit rescheduling points throughout kernel code.
  • Minor impact on throughput.
  • Used in: Ubuntu Desktop 15.04, Ubuntu Server 14.04

3rd option: preemptible kernel CONFIG_PREEMPT Most kernel code can be involuntarily preempted at any time. When a process becomes runnable, no more need to wait for kernel code (typically a system call) to return before running the scheduler.

  • Exception: kernel critical sections (holding spinlocks). In a case you hold a spinlock on a uni-processor system, kernel preemption could run another process, which would loop forever if it tried to acquire the same spinlock.
  • Typically for desktop or embedded systems with latency requirements in the milliseconds range.
  • Still a relatively minor impact on throughput.

Priority inheritance

One classical solution to the priority inversion problem is called priority inheritance

  • In Linux, since 2.6.18, mutexes support priority inheritance
  • In user space, priority inheritance must be explicitly enabled on a per-mutex basis.

High resolution timers

  • The resolution of the timers used to be bound to the resolution of the regular system tick
    • Usually 100 Hz or 250 Hz, depending on the architecture and the configuration
    • A resolution of only 10 ms or 4 ms.
    • Increasing the regular system tick frequency is not an option as it would consume too many resources
  • The high-resolution timers infrastructure, merged in 2.6.21, allows to use the available hardware timers to program interrupts at the right moment.
    • Hardware timers are multiplexed, so that a single hardware timer is sufficient to handle a large number of software-programmed timers.
    • Usable directly from user space using the usual timer APIs

Threaded interrupts

  • To solve the interrupt inversion problem, PREEMPT_RT has introduced the concept of threaded interrupts
  • The interrupt handlers run in normal kernel threads, so that the priorities of the different interrupt handlers can be configured
  • The real interrupt handler, as executed by the CPU, is only in charge of masking the interrupt and waking-up the corresponding thread
  • The idea of threaded interrupts also allows to use sleeping spinlocks (see later)
  • Merged since 2.6.30, the conversion of interrupt handlers to threaded interrupts is not automatic: drivers must be modified
  • In PREEMPT_RT, all interrupt handlers are switched to threaded interrupts

The future of the PREEMPT_RT patchset

  • Before Oct. 2015: project stalled because of the lack of funding. Thomas Gleixner still the maintainer but lacked time for further development and mainlining efforts. Patch releases only made for specific kernel releases.
  • Oct. 2015: the Linux Foundation at last got funding for mainlining the patchset into the Linux kernel (see http://lwn.net/Articles/659193/).
  • There's at last a good chance for the patchset to be merged by the end of 2016.

results matching ""

    No results matching ""