diff options
Diffstat (limited to 'arch/x86/Kconfig')
| -rw-r--r-- | arch/x86/Kconfig | 107 |
1 files changed, 107 insertions, 0 deletions
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 8689e794a43c..fe42b18409dc 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1002,6 +1002,22 @@ config NR_CPUS config SCHED_SMT def_bool y if SMP +config SMT_NICE + bool "SMT (Hyperthreading) aware nice priority and policy support" + depends on SCHED_MUQSS && SCHED_SMT + default y + ---help--- + Enabling Hyperthreading on Intel CPUs decreases the effectiveness + of the use of 'nice' levels and different scheduling policies + (e.g. realtime) due to sharing of CPU power between hyperthreads. + SMT nice support makes each logical CPU aware of what is running on + its hyperthread siblings, maintaining appropriate distribution of + CPU according to nice levels and scheduling policies at the expense + of slightly increased overhead. + + If unsure say Y here. + + config SCHED_MC def_bool y prompt "Multi-core scheduler support" @@ -1032,6 +1048,97 @@ config SCHED_MC_PRIO If unsure say Y here. +choice + prompt "CPU scheduler runqueue sharing" + default RQ_MC if SCHED_MUQSS + default RQ_NONE + +config RQ_NONE + bool "No sharing" + help + This is the default behaviour where the CPU scheduler has one runqueue + per CPU, whether it is a physical or logical CPU (hyperthread). + + This can still be enabled runtime with the boot parameter + rqshare=none + + If unsure, say N. + +config RQ_SMT + bool "SMT (hyperthread) siblings" + depends on SCHED_SMT && SCHED_MUQSS + + help + With this option enabled, the CPU scheduler will have one runqueue + shared by SMT (hyperthread) siblings. As these logical cores share + one physical core, sharing the runqueue resource can lead to decreased + overhead, lower latency and higher throughput. + + This can still be enabled runtime with the boot parameter + rqshare=smt + + If unsure, say N. + +config RQ_MC + bool "Multicore siblings" + depends on SCHED_MC && SCHED_MUQSS + help + With this option enabled, the CPU scheduler will have one runqueue + shared by multicore siblings in addition to any SMT siblings. + As these physical cores share caches, sharing the runqueue resource + will lead to lower latency, but its effects on overhead and throughput + are less predictable. As a general rule, 6 or fewer cores will likely + benefit from this, while larger CPUs will only derive a latency + benefit. If your workloads are primarily single threaded, this will + possibly worsen throughput. If you are only concerned about latency + then enable this regardless of how many cores you have. + + This can still be enabled runtime with the boot parameter + rqshare=mc + + If unsure, say Y. + +config RQ_SMP + bool "Symmetric Multi-Processing" + depends on SMP && SCHED_MUQSS + help + With this option enabled, the CPU scheduler will have one runqueue + shared by all physical CPUs unless they are on separate NUMA nodes. + As physical CPUs usually do not share resources, sharing the runqueue + will normally worsen throughput but improve latency. If you only + care about latency enable this. + + This can still be enabled runtime with the boot parameter + rqshare=smp + + If unsure, say N. + +config RQ_ALL + bool "NUMA" + depends on SMP && SCHED_MUQSS + help + With this option enabled, the CPU scheduler will have one runqueue + regardless of the architecture configuration, including across NUMA + nodes. This can substantially decrease throughput in NUMA + configurations, but light NUMA designs will not be dramatically + affected. This option should only be chosen if latency is the prime + concern. + + This can still be enabled runtime with the boot parameter + rqshare=all + + If unsure, say N. +endchoice + +config SHARERQ + int + default 0 if RQ_NONE + default 1 if RQ_SMT + default 2 if RQ_MC + default 3 if RQ_SMP + default 4 if RQ_ALL + + config UP_LATE_INIT def_bool y depends on !SMP && X86_LOCAL_APIC |