Fix a spelling mistake in the help text for PREEMPT_RT. Signed-off-by: Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/157204450499.10518.4542293884417101528.stgit@srivatsa-ubuntu
		
			
				
	
	
		
			83 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			83 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| # SPDX-License-Identifier: GPL-2.0-only
 | |
| 
 | |
| choice
 | |
| 	prompt "Preemption Model"
 | |
| 	default PREEMPT_NONE
 | |
| 
 | |
| config PREEMPT_NONE
 | |
| 	bool "No Forced Preemption (Server)"
 | |
| 	help
 | |
| 	  This is the traditional Linux preemption model, geared towards
 | |
| 	  throughput. It will still provide good latencies most of the
 | |
| 	  time, but there are no guarantees and occasional longer delays
 | |
| 	  are possible.
 | |
| 
 | |
| 	  Select this option if you are building a kernel for a server or
 | |
| 	  scientific/computation system, or if you want to maximize the
 | |
| 	  raw processing power of the kernel, irrespective of scheduling
 | |
| 	  latencies.
 | |
| 
 | |
| config PREEMPT_VOLUNTARY
 | |
| 	bool "Voluntary Kernel Preemption (Desktop)"
 | |
| 	depends on !ARCH_NO_PREEMPT
 | |
| 	help
 | |
| 	  This option reduces the latency of the kernel by adding more
 | |
| 	  "explicit preemption points" to the kernel code. These new
 | |
| 	  preemption points have been selected to reduce the maximum
 | |
| 	  latency of rescheduling, providing faster application reactions,
 | |
| 	  at the cost of slightly lower throughput.
 | |
| 
 | |
| 	  This allows reaction to interactive events by allowing a
 | |
| 	  low priority process to voluntarily preempt itself even if it
 | |
| 	  is in kernel mode executing a system call. This allows
 | |
| 	  applications to run more 'smoothly' even when the system is
 | |
| 	  under load.
 | |
| 
 | |
| 	  Select this if you are building a kernel for a desktop system.
 | |
| 
 | |
| config PREEMPT
 | |
| 	bool "Preemptible Kernel (Low-Latency Desktop)"
 | |
| 	depends on !ARCH_NO_PREEMPT
 | |
| 	select PREEMPTION
 | |
| 	select UNINLINE_SPIN_UNLOCK if !ARCH_INLINE_SPIN_UNLOCK
 | |
| 	help
 | |
| 	  This option reduces the latency of the kernel by making
 | |
| 	  all kernel code (that is not executing in a critical section)
 | |
| 	  preemptible.  This allows reaction to interactive events by
 | |
| 	  permitting a low priority process to be preempted involuntarily
 | |
| 	  even if it is in kernel mode executing a system call and would
 | |
| 	  otherwise not be about to reach a natural preemption point.
 | |
| 	  This allows applications to run more 'smoothly' even when the
 | |
| 	  system is under load, at the cost of slightly lower throughput
 | |
| 	  and a slight runtime overhead to kernel code.
 | |
| 
 | |
| 	  Select this if you are building a kernel for a desktop or
 | |
| 	  embedded system with latency requirements in the milliseconds
 | |
| 	  range.
 | |
| 
 | |
| config PREEMPT_RT
 | |
| 	bool "Fully Preemptible Kernel (Real-Time)"
 | |
| 	depends on EXPERT && ARCH_SUPPORTS_RT
 | |
| 	select PREEMPTION
 | |
| 	help
 | |
| 	  This option turns the kernel into a real-time kernel by replacing
 | |
| 	  various locking primitives (spinlocks, rwlocks, etc.) with
 | |
| 	  preemptible priority-inheritance aware variants, enforcing
 | |
| 	  interrupt threading and introducing mechanisms to break up long
 | |
| 	  non-preemptible sections. This makes the kernel, except for very
 | |
| 	  low level and critical code paths (entry code, scheduler, low
 | |
| 	  level interrupt handling) fully preemptible and brings most
 | |
| 	  execution contexts under scheduler control.
 | |
| 
 | |
| 	  Select this if you are building a kernel for systems which
 | |
| 	  require real-time guarantees.
 | |
| 
 | |
| endchoice
 | |
| 
 | |
| config PREEMPT_COUNT
 | |
|        bool
 | |
| 
 | |
| config PREEMPTION
 | |
|        bool
 | |
|        select PREEMPT_COUNT
 |