Scheduling policies are used, by the scheduler, to determine which task (e.g. process or thread) should be allowed to run next, and also how long that task should be allowed to run before it gets preempted. In Linux the default scheduling policy is SCHED_OTHER, also known as the Completely Fair Scheduler (CFS). Additionally, there are the “real-time” scheduling policies SCHED_RR (Round Robin), SCHED_FIFO and SCHED_DEADLINE (Global Earliest Deadline First).
Generally, tasks that use one of the “real-time” scheduling policies take precedence over “normal” tasks. Also, within the SCHED_RR and SCHED_FIFO policies, “static” priorities are used to determine the priority (urgency) of a task. Furthermore, tasks that use SCHED_DEADLINE take precedence over all other tasks, including those that use the SCHED_RR or SCHED_FIFO policy.
Kernel preemption is a different but related topic! Originally, the Linux kernel could not not be preempted at all: Whenever the kernel itself was running, there was no way to preempt the kernel code and switch to another task! In this situation, even using one of the “real-time” scheduling policies does not guarantee that your critical “real-time” task is going to run in due time – because the kernel might be busy doing something else and the scheduler simply will not get a chance for switching tasks until the kernel is done with whatever it was doing.
Over time, an increasing number of “explicit preemption points” have been added to the Linux code, allowing the kernel to be preempted at these specific points. This was done in order to improve the “responsiveness” of the system, e.g. in Desktop use-cases. But, for a “real” “real-time” system, i.e. one that gives you hard “real-time” guarantees, this still is not sufficient!
And that is exactly where PREEMPT_RT comes in: With this patch, the Linux kernel becomes completely preemptible, except for a few selected critical sections. The technical details are rather complicated, so I won’t even try to explain. See here if you need more details! What you need to understand about PREEMPT_RT is that this greatly improves the latency of the system, as is required for many “real-time” applications. But it also comes at a price: Due to the additional overhead, PREEMPT_RT almost certainly reduces the throughput of the system.
This explains why, even after it has been merged into mainline, PREEMPT_RT still is an opt-in feature that needs to be enabled at complile-time. It can not be switched on/off at runtime.
In summary: Yes, you can use the “real-time” scheduling policies, even on a Linux kernel that does not have PREEMPT_RT enabled. But, even though this will make your “real-time” task take precedence over “normal” tasks, it certainly will not give you the hard “real-time” guarantees that you would normally expect from a “real” “real-time” operating system (RTOS).
If you need hard “real-time” guarantees, then PREEMPT_RT is required. This will change how the Linux kernel works quite drastically, regardless of whether you use the “real-time” scheduling policies for your application(s). I assume most people who use PREEMPT_RT will do this in conjunction with SCHED_DEADLINE for their critical “real-time” task, but this is not a must. Also, you do not want to use PREEMPT_RT unless you actually need it, because it has downsides!