| 1 | # SPDX-License-Identifier: GPL-2.0-only |
| 2 | |
| 3 | config PREEMPT_NONE_BUILD |
| 4 | bool |
| 5 | |
| 6 | config PREEMPT_VOLUNTARY_BUILD |
| 7 | bool |
| 8 | |
| 9 | config PREEMPT_BUILD |
| 10 | bool |
| 11 | select PREEMPTION |
| 12 | select UNINLINE_SPIN_UNLOCK if !ARCH_INLINE_SPIN_UNLOCK |
| 13 | |
| 14 | choice |
| 15 | prompt "Preemption Model" |
| 16 | default PREEMPT_NONE |
| 17 | |
| 18 | config PREEMPT_NONE |
| 19 | bool "No Forced Preemption (Server)" |
| 20 | select PREEMPT_NONE_BUILD if !PREEMPT_DYNAMIC |
| 21 | help |
| 22 | This is the traditional Linux preemption model, geared towards |
| 23 | throughput. It will still provide good latencies most of the |
| 24 | time, but there are no guarantees and occasional longer delays |
| 25 | are possible. |
| 26 | |
| 27 | Select this option if you are building a kernel for a server or |
| 28 | scientific/computation system, or if you want to maximize the |
| 29 | raw processing power of the kernel, irrespective of scheduling |
| 30 | latencies. |
| 31 | |
| 32 | config PREEMPT_VOLUNTARY |
| 33 | bool "Voluntary Kernel Preemption (Desktop)" |
| 34 | depends on !ARCH_NO_PREEMPT |
| 35 | select PREEMPT_VOLUNTARY_BUILD if !PREEMPT_DYNAMIC |
| 36 | help |
| 37 | This option reduces the latency of the kernel by adding more |
| 38 | "explicit preemption points" to the kernel code. These new |
| 39 | preemption points have been selected to reduce the maximum |
| 40 | latency of rescheduling, providing faster application reactions, |
| 41 | at the cost of slightly lower throughput. |
| 42 | |
| 43 | This allows reaction to interactive events by allowing a |
| 44 | low priority process to voluntarily preempt itself even if it |
| 45 | is in kernel mode executing a system call. This allows |
| 46 | applications to run more 'smoothly' even when the system is |
| 47 | under load. |
| 48 | |
| 49 | Select this if you are building a kernel for a desktop system. |
| 50 | |
| 51 | config PREEMPT |
| 52 | bool "Preemptible Kernel (Low-Latency Desktop)" |
| 53 | depends on !ARCH_NO_PREEMPT |
| 54 | select PREEMPT_BUILD |
| 55 | help |
| 56 | This option reduces the latency of the kernel by making |
| 57 | all kernel code (that is not executing in a critical section) |
| 58 | preemptible. This allows reaction to interactive events by |
| 59 | permitting a low priority process to be preempted involuntarily |
| 60 | even if it is in kernel mode executing a system call and would |
| 61 | otherwise not be about to reach a natural preemption point. |
| 62 | This allows applications to run more 'smoothly' even when the |
| 63 | system is under load, at the cost of slightly lower throughput |
| 64 | and a slight runtime overhead to kernel code. |
| 65 | |
| 66 | Select this if you are building a kernel for a desktop or |
| 67 | embedded system with latency requirements in the milliseconds |
| 68 | range. |
| 69 | |
| 70 | config PREEMPT_RT |
| 71 | bool "Fully Preemptible Kernel (Real-Time)" |
| 72 | depends on EXPERT && ARCH_SUPPORTS_RT |
| 73 | select PREEMPTION |
| 74 | help |
| 75 | This option turns the kernel into a real-time kernel by replacing |
| 76 | various locking primitives (spinlocks, rwlocks, etc.) with |
| 77 | preemptible priority-inheritance aware variants, enforcing |
| 78 | interrupt threading and introducing mechanisms to break up long |
| 79 | non-preemptible sections. This makes the kernel, except for very |
| 80 | low level and critical code paths (entry code, scheduler, low |
| 81 | level interrupt handling) fully preemptible and brings most |
| 82 | execution contexts under scheduler control. |
| 83 | |
| 84 | Select this if you are building a kernel for systems which |
| 85 | require real-time guarantees. |
| 86 | |
| 87 | endchoice |
| 88 | |
| 89 | config PREEMPT_COUNT |
| 90 | bool |
| 91 | |
| 92 | config PREEMPTION |
| 93 | bool |
| 94 | select PREEMPT_COUNT |
| 95 | |
| 96 | config PREEMPT_DYNAMIC |
| 97 | bool "Preemption behaviour defined on boot" |
| 98 | depends on HAVE_PREEMPT_DYNAMIC && !PREEMPT_RT |
| 99 | select JUMP_LABEL if HAVE_PREEMPT_DYNAMIC_KEY |
| 100 | select PREEMPT_BUILD |
| 101 | default y if HAVE_PREEMPT_DYNAMIC_CALL |
| 102 | help |
| 103 | This option allows to define the preemption model on the kernel |
| 104 | command line parameter and thus override the default preemption |
| 105 | model defined during compile time. |
| 106 | |
| 107 | The feature is primarily interesting for Linux distributions which |
| 108 | provide a pre-built kernel binary to reduce the number of kernel |
| 109 | flavors they offer while still offering different usecases. |
| 110 | |
| 111 | The runtime overhead is negligible with HAVE_STATIC_CALL_INLINE enabled |
| 112 | but if runtime patching is not available for the specific architecture |
| 113 | then the potential overhead should be considered. |
| 114 | |
| 115 | Interesting if you want the same pre-built kernel should be used for |
| 116 | both Server and Desktop workloads. |
| 117 | |
| 118 | config SCHED_CORE |
| 119 | bool "Core Scheduling for SMT" |
| 120 | depends on SCHED_SMT |
| 121 | help |
| 122 | This option permits Core Scheduling, a means of coordinated task |
| 123 | selection across SMT siblings. When enabled -- see |
| 124 | prctl(PR_SCHED_CORE) -- task selection ensures that all SMT siblings |
| 125 | will execute a task from the same 'core group', forcing idle when no |
| 126 | matching task is found. |
| 127 | |
| 128 | Use of this feature includes: |
| 129 | - mitigation of some (not all) SMT side channels; |
| 130 | - limiting SMT interference to improve determinism and/or performance. |
| 131 | |
| 132 | SCHED_CORE is default disabled. When it is enabled and unused, |
| 133 | which is the likely usage by Linux distributions, there should |
| 134 | be no measurable impact on performance. |
| 135 | |
| 136 | config SCHED_CLASS_EXT |
| 137 | bool "Extensible Scheduling Class" |
| 138 | depends on BPF_SYSCALL && BPF_JIT && DEBUG_INFO_BTF |
| 139 | select STACKTRACE if STACKTRACE_SUPPORT |
| 140 | help |
| 141 | This option enables a new scheduler class sched_ext (SCX), which |
| 142 | allows scheduling policies to be implemented as BPF programs to |
| 143 | achieve the following: |
| 144 | |
| 145 | - Ease of experimentation and exploration: Enabling rapid |
| 146 | iteration of new scheduling policies. |
| 147 | - Customization: Building application-specific schedulers which |
| 148 | implement policies that are not applicable to general-purpose |
| 149 | schedulers. |
| 150 | - Rapid scheduler deployments: Non-disruptive swap outs of |
| 151 | scheduling policies in production environments. |
| 152 | |
| 153 | sched_ext leverages BPF struct_ops feature to define a structure |
| 154 | which exports function callbacks and flags to BPF programs that |
| 155 | wish to implement scheduling policies. The struct_ops structure |
| 156 | exported by sched_ext is struct sched_ext_ops, and is conceptually |
| 157 | similar to struct sched_class. |
| 158 | |
| 159 | For more information: |
| 160 | Documentation/scheduler/sched-ext.rst |
| 161 | https://github.com/sched-ext/scx |