Revisiting the kernel's preemption models (part 1)

> Ie. in the long run - after a careful period of observing performance
> regressions and other dragons - we'd only have *two* preemption modes left:

> !PREEMPT_RT # regular kernel. Single default behavior.
> PREEMPT_RT=y # -rt kernel, because rockets, satellites & cars matter.

> Any other application level preemption preferences can be expressed via
> scheduling policies & priorities.

PREEMPT_RT would still be a separate compile time option, due to the difficulty of switching locking primitives on the fly as mentioned in other comments here (and presumably switching to threaded interrupt handlers on the fly could be nontrivial as well). But the default behavior would be something similar to the current PREEMPT_NONE or PREEMPT_VOLUNTARY for non-RT processes, and similar to the current full PREEMPT ("low latency desktop") for RT processes. Best of both worlds.