Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull CONFIG_PREEMPT_RT stub config from Thomas Gleixner:
"The real-time preemption patch set exists for almost 15 years now and
while the vast majority of infrastructure and enhancements have found
their way into the mainline kernel, the final integration of RT is
still missing.

Over the course of the last few years, we have worked on reducing the
intrusivenness of the RT patches by refactoring kernel infrastructure
to be more real-time friendly. Almost all of these changes were
benefitial to the mainline kernel on their own, so there was no
objection to integrate them.

Though except for the still ongoing printk refactoring, the remaining
changes which are required to make RT a first class mainline citizen
are not longer arguable as immediately beneficial for the mainline
kernel. Most of them are either reordering code flows or adding RT
specific functionality.

But this now has hit a wall and turned into a classic hen and egg
problem:

Maintainers are rightfully wary vs. these changes as they make only
sense if the final integration of RT into the mainline kernel takes
place.

Adding CONFIG_PREEMPT_RT aims to solve this as a clear sign that RT
will be fully integrated into the mainline kernel. The final
integration of the missing bits and pieces will be of course done with
the same careful approach as we have used in the past.

While I'm aware that you are not entirely enthusiastic about that, I
think that RT should receive the same treatment as any other widely
used out of tree functionality, which we have accepted into mainline
over the years.

RT has become the de-facto standard real-time enhancement and is
shipped by enterprise, embedded and community distros. It's in use
throughout a wide range of industries: telecommunications, industrial
automation, professional audio, medical devices, data acquisition,
automotive - just to name a few major use cases.

RT development is backed by a Linuxfoundation project which is
supported by major stakeholders of this technology. The funding will
continue over the actual inclusion into mainline to make sure that the
functionality is neither introducing regressions, regressing itself,
nor becomes subject to bitrot. There is also a lifely user community
around RT as well, so contrary to the grim situation 5 years ago, it's
a healthy project.

As RT is still a good vehicle to exercise rarely used code paths and
to detect hard to trigger issues, you could at least view it as a QA
tool if nothing else"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/rt, Kconfig: Introduce CONFIG_PREEMPT_RT

+26 -2
+3
arch/Kconfig
··· 796 796 config ARCH_NO_PREEMPT 797 797 bool 798 798 799 + config ARCH_SUPPORTS_RT 800 + bool 801 + 799 802 config CPU_NO_EFFICIENT_FFS 800 803 def_bool n 801 804
+23 -2
kernel/Kconfig.preempt
··· 35 35 36 36 Select this if you are building a kernel for a desktop system. 37 37 38 - config PREEMPT 38 + config PREEMPT_LL 39 39 bool "Preemptible Kernel (Low-Latency Desktop)" 40 40 depends on !ARCH_NO_PREEMPT 41 - select PREEMPT_COUNT 41 + select PREEMPT 42 42 select UNINLINE_SPIN_UNLOCK if !ARCH_INLINE_SPIN_UNLOCK 43 43 help 44 44 This option reduces the latency of the kernel by making ··· 55 55 embedded system with latency requirements in the milliseconds 56 56 range. 57 57 58 + config PREEMPT_RT 59 + bool "Fully Preemptible Kernel (Real-Time)" 60 + depends on EXPERT && ARCH_SUPPORTS_RT 61 + select PREEMPT 62 + help 63 + This option turns the kernel into a real-time kernel by replacing 64 + various locking primitives (spinlocks, rwlocks, etc.) with 65 + preemptible priority-inheritance aware variants, enforcing 66 + interrupt threading and introducing mechanisms to break up long 67 + non-preemptible sections. This makes the kernel, except for very 68 + low level and critical code pathes (entry code, scheduler, low 69 + level interrupt handling) fully preemptible and brings most 70 + execution contexts under scheduler control. 71 + 72 + Select this if you are building a kernel for systems which 73 + require real-time guarantees. 74 + 58 75 endchoice 59 76 60 77 config PREEMPT_COUNT 61 78 bool 79 + 80 + config PREEMPT 81 + bool 82 + select PREEMPT_COUNT