Support Intel Turbo Boost Max Technology 3.0
Subsystems (6)
v8 cover Support Intel Turbo Boost Max Technology 3.0
With Intel Turbo Boost Max Technology 3.0 (ITMT), single-threaded performance is optimized by identifying processor's fastest core and running critical workloads on it.
This patchset consist of all changes required to support ITMT feature:
- Use CPPC information in Intel P-State driver to get performance information
- Scheduler enhancements
- cppc lib patches (split in to a seprate series)
This featured can be enabled by writing at runtime
# echo 1 > /proc/sys/kernel/sched_itmt_enabled This featured can be disabled by writing at runtime # echo 0 > /proc/sys/kernel/sched_itmt_enabled
Change Log:
v8:
1. Remove arch_asym_max_cpu_and function and implement the logic explicitly in nohz_kick_needed.
v7:
1. ITMT3.0 is enabled by default also for multi-socket systems supporting the feature. Remove single socket restriction.
2. Add proper ASYM_PACKING check for high priority idle cpu in nohz_kick_needed.
3. Nulling of itmt_sysctl_header after sysctl table unregistration.
4. Minor code format cleanups.
5. Fix build issue on i386
v6:
- Split ITMT support control by OS into sched_set_itmt_support and sched_clear_itmt_support functions.
- Return error when we set sysctl_sched_itmt_enabled, if system does not support ITMT, or when we cannot create sysctl table entry.
- Minor code clean up and moving definition of sched_core_priority to top of file.
- Rebase on v4.9-rc1
v5:
- Simplify intel_pstate for enabling ITMT feature
- Put x86_sched_itmt_flags related functions under proper CONFIG_SCHED_MC/SMT flags
- Comment to note that rebuild_sched_domain is not needed after updating CPU priorities.
- Define sysctl_sched_itmt_enabled to 0 when ITMT is not used in arch/x86/include/asm/topology.h
- Dropped patch "Fix numa in package topology bug", as this is already applied
v4:
- Split x86 multi-node numa topology bug fix and setting
of SD_ASYM flag for ITMT topology into 2 patches
- Split the sysctl changes for ITMT enablement and setting of ITMT capability/core priorities into 2 patches.
- Avoid unnecessary rebuild of sched domains when ITMT sysctl or capabilities are updated.
- Fix missing stub function for topology_max_packages for !SMP case.
- Rename set_sched_itmt() to sched_set_itmt_support().
- Various updates to itmt.c to eliminate goto and make logic tighter.
- Various change logs and comments update.
- intel_pstate: Split function to process cppc and enable ITMT
- intel_pstate: Just keep the cppc_perf information till we use CPPC for HWP
v3:
- Fix race clash when more than one program are enabling/disabling ITMT
- Remove group_priority_cpu macro to simplify code.
- Error reported by 0-day for compile issue on ARM
v2
- The patchset is split into two parts so that CPPC changes can be merged first
1. Only ACPI CPPC changes (It is posted separately)
2. ITMT changes (scheduler and Intel P-State)
- Changes in patch: sched,x86: Enable Turbo Boost Max Technology
1. Use arch_update_cpu_topology to indicate need to completely rebuild sched domain when ITMT related sched domain flags change
2. Enable client (single node) platform capable of ITMT with ITMT scheduling by default
3. Implement arch_asym_cpu_priority to provide the cpu priority value to scheduler for asym packing.
4. Fix a compile bug for i386 architecture.
- Changes in patch: sched: Extend scheduler's asym packing
1. Use arch_asym_cpu_priority() to provide cpu priority value used for asym packing to the scheduler.
- Changes in acpi: bus: Enable HWP CPPC objects and
acpi: bus: Set _OSC for diverse core support
Minor code cleanup by removing #ifdef
- Changes in Kconfig for Intel P-State
Avoid building CPPC lib for i386 for issue reported by 0-day
- Feature is enabled by default for single socket systems
Rafael J. Wysocki (1):
cpufreq: intel_pstate: Use CPPC to get max performance
Srinivas Pandruvada (2):
acpi: bus: Enable HWP CPPC objects
acpi: bus: Set _OSC for diverse core support
Tim Chen (5):
sched: Extend scheduler's asym packing x86/topology: Define x86's arch_update_cpu_topology
x86: Enable Intel Turbo Boost Max Technology 3.0 x86/sysctl: Add sysctl for ITMT scheduling feature x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU
arch/x86/Kconfig | 9 ++ arch/x86/include/asm/topology.h | 32 ++++++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/itmt.c | 215 ++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/smpboot.c | 39 +++++++- drivers/acpi/bus.c | 10 ++ drivers/cpufreq/Kconfig.x86 | 1 + drivers/cpufreq/intel_pstate.c | 56 ++++++++++- include/linux/acpi.h | 1 + include/linux/sched.h | 4 + kernel/sched/core.c | 15 +++ kernel/sched/fair.c | 54 ++++++---- kernel/sched/sched.h | 6 ++ 13 files changed, 421 insertions(+), 22 deletions(-) create mode 100644 arch/x86/kernel/itmt.c
Signature · 1 line
2.5.5
PATCH v8 1/8 sched: Extend scheduler's asym packing
We generalize the scheduler's asym packing to provide an ordering of the cpu beyond just the cpu number. This allows the use of the ASYM_PACKING scheduler machinery to move loads to preferred CPU in a sched domain. The preference is defined with the cpu priority given by arch_asym_cpu_priority(cpu).
We also record the most preferred cpu in a sched group when we build the cpu's capacity for fast lookup of preferred cpu during load balancing.
--- include/linux/sched.h | 4 ++++ kernel/sched/core.c | 15 ++++++++++++++ kernel/sched/fair.c | 54 +++++++++++++++++++++++++++++++++++---------------- kernel/sched/sched.h | 6 ++++++ 4 files changed, 62 insertions(+), 17 deletions(-)
include/linux/sched.h +4 -0
@@ -1057,6 +1057,10 @@ static inline int cpu_numa_flags(void) }#endif +int arch_asym_cpu_priority (int cpu); +int arch_asym_max_cpu_and (const struct cpumask *mask1, +const struct cpumask *mask2); +struct sched_domain_attr {int relax_domain_level; };
kernel/sched/core.c +15 -0
@@ -6301,7 +6301,22 @@ static void init_sched_groups_capacity(int cpu, struct sched_domain *sd)WARN_ON (!sg);do { +int cpu, max_cpu =-1 ; + sg->group_weight =cpumask_weight (sched_group_cpus (sg)); + +if (!(sd->flags &SD_ASYM_PACKING )) + goto next; + +for_each_cpu (cpu,sched_group_cpus (sg)) { +if (max_cpu <0 ) + max_cpu = cpu; +else if (sched_asym_prefer (cpu, max_cpu)) + max_cpu = cpu; + } + sg->asym_prefer_cpu = max_cpu; + +next: sg = sg->next; }while (sg != sd->groups);
kernel/sched/fair.c +37 -17
96 lines not on this page · raw message
kernel/sched/sched.h +6 -0
@@ -539,6 +539,11 @@ struct dl_rq {#ifdef CONFIG_SMP +static inline bool sched_asym_prefer (int a,int b) +{ +return arch_asym_cpu_priority (a) >arch_asym_cpu_priority (b); +} +/* * We add the notion of a root-domain which will be used to define per-domain * variables. Each exclusive cpuset essentially defines an island domain by
@@ -905,6 +910,7 @@ struct sched_group {unsigned int group_weight;struct sched_group_capacity *sgc; +int asym_prefer_cpu;/* cpu of highest priority in group */ /* * The CPUs this group covers.
Signature · 1 line
2.5.5
Re: [PATCH v8 1/8] sched: Extend scheduler's asym packing
Quoted 6 lines · Tim Chen
We generalize the scheduler's asym packing to provide an ordering of the cpu beyond just the cpu number. This allows the use of the
ASYM_PACKINGscheduler machinery to move loads to preferred CPU in a sched domain. The preference is defined with the cpu priority given byarch_asym_cpu_priority(cpu).
Quoted 6 lines
We also record the most preferred cpu in a sched group when we build the cpu's capacity for fast lookup of preferred cpu during load balancing.
Co-developed-by Peter Zijlstra (Intel) <[email protected]>Signed-off-by Tim Chen <[email protected]>
With the two little edits below:
Quoted 12 lines
--- include/linux/sched.h | 4 ++++ kernel/sched/core.c | 15 ++++++++++++++ kernel/sched/fair.c | 54 +++++++++++++++++++++++++++++++++++---------------- kernel/sched/sched.h | 6 ++++++ 4 files changed, 62 insertions(+), 17 deletions(-)include/linux/sched.h +0
-0
include/linux/sched.h static inline int cpu_numa_flags(void) · line 1060
Quoted 4 lines
include/linux/sched.h +1
-0@@ -1057,6 +1057,10 @@ static inline int cpu_numa_flags(void) }#endif +int arch_asym_cpu_priority (int cpu);
extern
include/linux/sched.h static inline int cpu_numa_flags(void) · line 1063
Quoted 3 lines
include/linux/sched.h +3
-0+int arch_asym_max_cpu_and (const struct cpumask *mask1, +const struct cpumask *mask2); +
And that needs to go too; that function no longer exists.
Quoted 3 lines
include/linux/sched.h +0
-0struct sched_domain_attr {int relax_domain_level; };
Tim Chen
Acked-by Peter Zijlstra (Intel)Re: [PATCH v8 1/8] sched: Extend scheduler's asym packing
Quoted 24 lines · Peter Zijlstra
With the two little edits below:
Quoted 12 lines
--- include/linux/sched.h | 4 ++++ kernel/sched/core.c | 15 ++++++++++++++ kernel/sched/fair.c | 54 +++++++++++++++++++++++++++++++++++---------------- kernel/sched/sched.h | 6 ++++++ 4 files changed, 62 insertions(+), 17 deletions(-)include/linux/sched.h +0
-0include/linux/sched.h static inline int cpu_numa_flags(void) · line 1060
Quoted 4 lines
include/linux/sched.h +1
-0@@ -1057,6 +1057,10 @@ static inline int cpu_numa_flags(void) }#endif +int arch_asym_cpu_priority (int cpu);extern
Quoted 9 lines
include/linux/sched.h static inline int cpu_numa_flags(void) · line 1063
Quoted 3 lines
include/linux/sched.h +3
-0+int arch_asym_max_cpu_and (const struct cpumask *mask1, +const struct cpumask *mask2); +And that needs to go too; that function no longer exists.
Quoted 3 lines
include/linux/sched.h +0
-0struct sched_domain_attr {int relax_domain_level; };
Thanks for catching that. The patch updated below.
Tim
---->8----
From: Tim Chen <[email protected]>
Subject: [PATCH v8 1/8] sched: Extend scheduler's asym packing
To: [email protected], [email protected], [email protected], [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], Tim Chen <[email protected]>, [email protected], Srinivas Pandruvada <[email protected]>
We generalize the scheduler's asym packing to provide an ordering of the cpu beyond just the cpu number. This allows the use of the ASYM_PACKING scheduler machinery to move loads to preferred CPU in a sched domain. The preference is defined with the cpu priority given by arch_asym_cpu_priority(cpu).
We also record the most preferred cpu in a sched group when we build the cpu's capacity for fast lookup of preferred cpu during load balancing.
--- include/linux/sched.h | 2 ++ kernel/sched/core.c | 15 ++++++++++++++ kernel/sched/fair.c | 54 +++++++++++++++++++++++++++++++++++---------------- kernel/sched/sched.h | 6 ++++++ 4 files changed, 60 insertions(+), 17 deletions(-)
include/linux/sched.h +2 -0
@@ -1057,6 +1057,8 @@ static inline int cpu_numa_flags(void) }#endif +extern int arch_asym_cpu_priority (int cpu); +struct sched_domain_attr {int relax_domain_level; };
kernel/sched/core.c +15 -0
@@ -6301,7 +6301,22 @@ static void init_sched_groups_capacity(int cpu, struct sched_domain *sd)WARN_ON (!sg);do { +int cpu, max_cpu =-1 ; + sg->group_weight =cpumask_weight (sched_group_cpus (sg)); + +if (!(sd->flags &SD_ASYM_PACKING )) + goto next; + +for_each_cpu (cpu,sched_group_cpus (sg)) { +if (max_cpu <0 ) + max_cpu = cpu; +else if (sched_asym_prefer (cpu, max_cpu)) + max_cpu = cpu; + } + sg->asym_prefer_cpu = max_cpu; + +next: sg = sg->next; }while (sg != sd->groups);
kernel/sched/fair.c +37 -17
96 lines not on this page · raw message
kernel/sched/sched.h +6 -0
@@ -539,6 +539,11 @@ struct dl_rq {#ifdef CONFIG_SMP +static inline bool sched_asym_prefer (int a,int b) +{ +return arch_asym_cpu_priority (a) >arch_asym_cpu_priority (b); +} +/* * We add the notion of a root-domain which will be used to define per-domain * variables. Each exclusive cpuset essentially defines an island domain by
@@ -905,6 +910,7 @@ struct sched_group {unsigned int group_weight;struct sched_group_capacity *sgc; +int asym_prefer_cpu;/* cpu of highest priority in group */ /* * The CPUs this group covers.
Signature · 1 line
2.5.5
tip-bot for Tim Chen
merge bot[tip:sched/core] sched: Extend scheduler's asym packing
In reply to Tim Chensched: Extend scheduler's asym packing
Commit-ID: afe06efdf07c12fd9370d5cce5383398cedf6c90 Gitweb: http://git.kernel.org/tip/afe06efdf07c12fd9370d5cce5383398cedf6c90 Author: Tim Chen <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:53 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 14:09:46 +0100
sched: Extend scheduler's asym packing
We generalize the scheduler's asym packing to provide an ordering of the cpu beyond just the cpu number. This allows the use of the ASYM_PACKING scheduler machinery to move loads to preferred CPU in a sched domain. The preference is defined with the cpu priority given by arch_asym_cpu_priority(cpu).
We also record the most preferred cpu in a sched group when we build the cpu's capacity for fast lookup of preferred cpu during load balancing.
--- include/linux/sched.h | 2 ++ kernel/sched/core.c | 15 +++++++++++++++ kernel/sched/fair.c | 53 ++++++++++++++++++++++++++++++++++----------------- kernel/sched/sched.h | 6 ++++++ 4 files changed, 59 insertions(+), 17 deletions(-)
include/linux/sched.h +2 -0
@@ -1077,6 +1077,8 @@ static inline int cpu_numa_flags(void) }#endif +extern int arch_asym_cpu_priority (int cpu); +struct sched_domain_attr {int relax_domain_level; };
kernel/sched/core.c +15 -0
@@ -6303,7 +6303,22 @@ static void init_sched_groups_capacity(int cpu, struct sched_domain *sd)WARN_ON (!sg);do { +int cpu, max_cpu =-1 ; + sg->group_weight =cpumask_weight (sched_group_cpus (sg)); + +if (!(sd->flags &SD_ASYM_PACKING )) + goto next; + +for_each_cpu (cpu,sched_group_cpus (sg)) { +if (max_cpu <0 ) + max_cpu = cpu; +else if (sched_asym_prefer (cpu, max_cpu)) + max_cpu = cpu; + } + sg->asym_prefer_cpu = max_cpu; + +next: sg = sg->next; }while (sg != sd->groups);
kernel/sched/fair.c +36 -17
95 lines not on this page · raw message
kernel/sched/sched.h +6 -0
@@ -540,6 +540,11 @@ struct dl_rq {#ifdef CONFIG_SMP +static inline bool sched_asym_prefer (int a,int b) +{ +return arch_asym_cpu_priority (a) >arch_asym_cpu_priority (b); +} +/* * We add the notion of a root-domain which will be used to define per-domain * variables. Each exclusive cpuset essentially defines an island domain by
@@ -908,6 +913,7 @@ struct sched_group {unsigned int group_weight;struct sched_group_capacity *sgc; +int asym_prefer_cpu;/* cpu of highest priority in group */ /* * The CPUs this group covers.
PATCH v8 2/8 x86/topology: Define x86's arch_update_cpu_topology
In reply to Tim ChenThe scheduler calls arch_update_cpu_topology() to check whether the scheduler domains have to be rebuilt.
So far x86 has no requirement for this, but the upcoming ITMT support makes this necessary.
Request the rebuild when the x86 internal update flag is set.
--- arch/x86/include/asm/topology.h | 1 + arch/x86/kernel/smpboot.c | 11 +++++++++++ 2 files changed, 12 insertions(+)
arch/x86/include/asm/topology.h +1 -0
@@ -146,4 +146,5 @@ struct pci_bus;int x86_pci_root_bus_node (int bus);void x86_pci_root_bus_resources (int bus,struct list_head *resources); +extern bool x86_topology_update;#endif /* _ASM_X86_TOPOLOGY_H */
arch/x86/kernel/smpboot.c +11 -0
@@ -109,6 +109,17 @@ static bool logical_packages_frozen __read_mostly;/* Maximum number of SMT threads on any online core */ int __max_smt_threads__read_mostly ; +/* Flag to indicate if a complete sched domain rebuild is required */ +bool x86_topology_update; + +int arch_update_cpu_topology (void ) +{ +int retval = x86_topology_update; + + x86_topology_update = false; +return retval; +} +static inline void smpboot_setup_warm_reset_vector (unsigned long start_eip) {unsigned long flags;
Signature · 1 line
2.5.5
tip-bot for Tim Chen
merge bot[tip:x86/core] x86/topology: Define x86's arch_update_cpu_topology
x86/topology: Define x86's arch_update_cpu_topology
Commit-ID: 7d25127cef44924f1013d119ba385095ca4b4a83 Gitweb: http://git.kernel.org/tip/7d25127cef44924f1013d119ba385095ca4b4a83 Author: Tim Chen <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:54 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:19 +0100
x86/topology: Define x86's arch_update_cpu_topology
The scheduler calls arch_update_cpu_topology() to check whether the scheduler domains have to be rebuilt.
So far x86 has no requirement for this, but the upcoming ITMT support makes this necessary.
Request the rebuild when the x86 internal update flag is set.
--- arch/x86/include/asm/topology.h | 1 + arch/x86/kernel/smpboot.c | 11 +++++++++++ 2 files changed, 12 insertions(+)
arch/x86/include/asm/topology.h +1 -0
@@ -146,4 +146,5 @@ struct pci_bus;int x86_pci_root_bus_node (int bus);void x86_pci_root_bus_resources (int bus,struct list_head *resources); +extern bool x86_topology_update;#endif /* _ASM_X86_TOPOLOGY_H */
arch/x86/kernel/smpboot.c +11 -0
@@ -109,6 +109,17 @@ static bool logical_packages_frozen __read_mostly;/* Maximum number of SMT threads on any online core */ int __max_smt_threads__read_mostly ; +/* Flag to indicate if a complete sched domain rebuild is required */ +bool x86_topology_update; + +int arch_update_cpu_topology (void ) +{ +int retval = x86_topology_update; + + x86_topology_update = false; +return retval; +} +static inline void smpboot_setup_warm_reset_vector (unsigned long start_eip) {unsigned long flags;
PATCH v8 3/8 x86: Enable Intel Turbo Boost Max Technology 3.0
In reply to Tim ChenOn platforms supporting Intel Turbo Boost Max Technology 3.0, the maximum turbo frequencies of some cores in a CPU package may be higher than for the other cores in the same package. In that case, better performance (and possibly lower energy consumption as well) can be achieved by making the scheduler prefer to run tasks on the CPUs with higher max turbo frequencies.
To that end, set up a core priority metric to abstract the core preferences based on the maximum turbo frequency. In that metric, the cores with higher maximum turbo frequencies are higher-priority than the other cores in the same package and that causes the scheduler to favor them when making load-balancing decisions using the asymmertic packing approach. At the same time, the priority of SMT threads with a higher CPU number is reduced so as to avoid scheduling tasks on all of the threads that belong to a favored core before all of the other cores have been given a task to run.
The priority metric will be initialized by the P-state driver with the help of the sched_set_itmt_core_prio() function. The P-state driver will also determine whether or not ITMT is supported by the platform and will call sched_set_itmt_support() to indicate that.
--- arch/x86/Kconfig | 9 ++++ arch/x86/include/asm/topology.h | 28 +++++++++++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/itmt.c | 109 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 147 insertions(+) create mode 100644 arch/x86/kernel/itmt.c
arch/x86/Kconfig +9 -0
@@ -939,6 +939,15 @@ config SCHED_MC making when dealing with multi-core CPU chips at a cost of slightly increased overhead in some places. If unsure say N here. +config SCHED_ITMT + bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + ---help--- + ITMT enabled scheduler support improves the CPU scheduler's decision + to move tasks to cpu core that can be boosted to a higher frequency + than others. It will have better performance at a cost of slightly + increased overhead in task migrations. If unsure say N here. + source "kernel/Kconfig.preempt" config UP_LATE_INIT
arch/x86/include/asm/topology.h +28 -0
@@ -147,4 +147,32 @@ int x86_pci_root_bus_node(int bus);void x86_pci_root_bus_resources (int bus,struct list_head *resources);extern bool x86_topology_update; + +#ifdef CONFIG_SCHED_ITMT +#include <asm/percpu.h> + +DECLARE_PER_CPU_READ_MOSTLY (int, sched_core_priority); + +/* Interface to set priority of a cpu */ +void sched_set_itmt_core_prio (int prio,int core_cpu); + +/* Interface to notify scheduler that system supports ITMT */ +void sched_set_itmt_support (void ); + +/* Interface to notify scheduler that system revokes ITMT support */ +void sched_clear_itmt_support (void ); + +#else /* CONFIG_SCHED_ITMT */ + +static inline void sched_set_itmt_core_prio (int prio,int core_cpu) +{ +} +static inline void sched_set_itmt_support (void ) +{ +} +static inline void sched_clear_itmt_support (void ) +{ +} +#endif /* CONFIG_SCHED_ITMT */ +#endif /* _ASM_X86_TOPOLOGY_H */
arch/x86/kernel/Makefile +1 -0
@@ -123,6 +123,7 @@ obj-$(CONFIG_EFI) += sysfb_efi.o obj-$(CONFIG_PERF_EVENTS) += perf_regs.o obj-$(CONFIG_TRACING) += tracepoint.o +obj-$(CONFIG_SCHED_ITMT) += itmt.o ifdef CONFIG_FRAME_POINTER obj-y += unwind_frame.o
arch/x86/kernel/itmt.c new file +109 -0
109 lines not on this page · raw message
Signature · 1 line
2.5.5
tip-bot for Tim Chen
merge bot[tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
x86: Enable Intel Turbo Boost Max Technology 3.0
Commit-ID: 5e76b2ab36b40ca33023e78725bdc69eafd63134 Gitweb: http://git.kernel.org/tip/5e76b2ab36b40ca33023e78725bdc69eafd63134 Author: Tim Chen <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:55 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:19 +0100
x86: Enable Intel Turbo Boost Max Technology 3.0
On platforms supporting Intel Turbo Boost Max Technology 3.0, the maximum turbo frequencies of some cores in a CPU package may be higher than for the other cores in the same package. In that case, better performance (and possibly lower energy consumption as well) can be achieved by making the scheduler prefer to run tasks on the CPUs with higher max turbo frequencies.
To that end, set up a core priority metric to abstract the core preferences based on the maximum turbo frequency. In that metric, the cores with higher maximum turbo frequencies are higher-priority than the other cores in the same package and that causes the scheduler to favor them when making load-balancing decisions using the asymmertic packing approach. At the same time, the priority of SMT threads with a higher CPU number is reduced so as to avoid scheduling tasks on all of the threads that belong to a favored core before all of the other cores have been given a task to run.
The priority metric will be initialized by the P-state driver with the help of the sched_set_itmt_core_prio() function. The P-state driver will also determine whether or not ITMT is supported by the platform and will call sched_set_itmt_support() to indicate that.
--- arch/x86/Kconfig | 9 ++++ arch/x86/include/asm/topology.h | 28 +++++++++++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/itmt.c | 109 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 147 insertions(+)
arch/x86/Kconfig +9 -0
@@ -939,6 +939,15 @@ config SCHED_MC making when dealing with multi-core CPU chips at a cost of slightly increased overhead in some places. If unsure say N here. +config SCHED_ITMT + bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + ---help--- + ITMT enabled scheduler support improves the CPU scheduler's decision + to move tasks to cpu core that can be boosted to a higher frequency + than others. It will have better performance at a cost of slightly + increased overhead in task migrations. If unsure say N here. + source "kernel/Kconfig.preempt" config UP_LATE_INIT
arch/x86/include/asm/topology.h +28 -0
@@ -147,4 +147,32 @@ int x86_pci_root_bus_node(int bus);void x86_pci_root_bus_resources (int bus,struct list_head *resources);extern bool x86_topology_update; + +#ifdef CONFIG_SCHED_ITMT +#include <asm/percpu.h> + +DECLARE_PER_CPU_READ_MOSTLY (int, sched_core_priority); + +/* Interface to set priority of a cpu */ +void sched_set_itmt_core_prio (int prio,int core_cpu); + +/* Interface to notify scheduler that system supports ITMT */ +void sched_set_itmt_support (void ); + +/* Interface to notify scheduler that system revokes ITMT support */ +void sched_clear_itmt_support (void ); + +#else /* CONFIG_SCHED_ITMT */ + +static inline void sched_set_itmt_core_prio (int prio,int core_cpu) +{ +} +static inline void sched_set_itmt_support (void ) +{ +} +static inline void sched_clear_itmt_support (void ) +{ +} +#endif /* CONFIG_SCHED_ITMT */ +#endif /* _ASM_X86_TOPOLOGY_H */
arch/x86/kernel/Makefile +1 -0
@@ -123,6 +123,7 @@ obj-$(CONFIG_EFI) += sysfb_efi.o obj-$(CONFIG_PERF_EVENTS) += perf_regs.o obj-$(CONFIG_TRACING) += tracepoint.o +obj-$(CONFIG_SCHED_ITMT) += itmt.o ifdef CONFIG_FRAME_POINTER obj-y += unwind_frame.o
arch/x86/kernel/itmt.c new file +109 -0
109 lines not on this page · raw message
Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
Quoted 8 lines · tip-bot for Tim Chen
Commit-ID: 5e76b2ab36b40ca33023e78725bdc69eafd63134 Gitweb: http://git.kernel.org/tip/5e76b2ab36b40ca33023e78725bdc69eafd63134 Author: Tim Chen <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:55 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:19 +0100x86: Enable Intel Turbo Boost Max Technology 3.0
This patch doesn't build:
Note that this patch has to be redone anyway, as it won't even build:
arch/x86/kernel/itmt.c line 29
Quoted 7 lines
arch/x86/kernel/itmt.c new file +7
-0+#include <linux/sched.h> +#include <linux/cpumask.h> +#include <linux/cpuset.h> +#include <asm/mutex.h> +#include <linux/sched.h> +#include <linux/sysctl.h> +#include <linux/nodemask.h>
arch/x86/kernel/itmt.c:26:23: fatal error: asm/mutex.h: No such file or directory
arch/x86/Kconfig config SCHED_MC · line 949
Quoted 8 lines
arch/x86/Kconfig +8
-0+config SCHED_ITMT + bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + ---help--- + ITMT enabled scheduler support improves the CPU scheduler's decision + to move tasks to cpu core that can be boosted to a higher frequency + than others. It will have better performance at a cost of slightly + increased overhead in task migrations. If unsure say N here.
Argh, so the 'itmt' name really sucks as well - could we please make it something more obvious - like SCHED_INTEL_TURBO or so - and similarly rename the file as well?
The sched_intel_turbo.c file could thus host all things related to scheduler support of turbo frequencies - it shouldn't be named after the Intel acronym of the day...
Thanks,
Ingo
Peter Zijlstra
maintainerRe: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
Quoted 16 lines · Ingo Molnar
Quoted 8 lines · tip-bot for Tim Chen
Commit-ID: 5e76b2ab36b40ca33023e78725bdc69eafd63134 Gitweb: http://git.kernel.org/tip/5e76b2ab36b40ca33023e78725bdc69eafd63134 Author: Tim Chen <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:55 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:19 +0100x86: Enable Intel Turbo Boost Max Technology 3.0
This patch doesn't build:
Note that this patch has to be redone anyway, as it won't even build:
Quoted 9 lines
arch/x86/kernel/itmt.c line 29
Quoted 7 lines
arch/x86/kernel/itmt.c new file +7
-0+#include <linux/sched.h> +#include <linux/cpumask.h> +#include <linux/cpuset.h> +#include <asm/mutex.h> +#include <linux/sched.h> +#include <linux/sysctl.h> +#include <linux/nodemask.h>
arch/x86/kernel/itmt.c:26:23: fatal error:asm/mutex.h: No such file or directory
Hehe, indeed, we killed that dead in the locking branch. Weird include to have anyway.
Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
In reply to Ingo MolnarQuoted 10 lines · Ingo Molnar
Quoted 7 lines · tip-bot for Tim Chen
Commit-ID: 5e76b2ab36b40ca33023e78725bdc69eafd63134 Gitweb: http://git.kernel.org/tip/5e76b2ab36b40ca33023e78725bdc69eafd63134 Author: Tim Chen <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:55 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:19 +0100
Quoted 5 lines
Quoted 1 line
x86: Enable Intel Turbo Boost Max Technology 3.0
This patch doesn't build:
Note that this patch has to be redone anyway, as it won't even build:
The branch where I merged it to builds fine.
Though, yes I missed the asm/mutex.h include which obviously should be linux/mutex.h
Quoted 23 lines
arch/x86/kernel/itmt.c line 29
Quoted 7 lines
arch/x86/kernel/itmt.c new file +7
-0+#include <linux/sched.h> +#include <linux/cpumask.h> +#include <linux/cpuset.h> +#include <asm/mutex.h> +#include <linux/sched.h> +#include <linux/sysctl.h> +#include <linux/nodemask.h>
arch/x86/kernel/itmt.c:26:23: fatal error:asm/mutex.h: No such file or directoryarch/x86/Kconfig config SCHED_MC · line 949
Quoted 8 lines
arch/x86/Kconfig +8
-0+config SCHED_ITMT + bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + ---help--- + ITMT enabled scheduler support improves the CPU scheduler's decision + to move tasks to cpu core that can be boosted to a higher frequency + than others. It will have better performance at a cost of slightly + increased overhead in task migrations. If unsure say N here.Argh, so the 'itmt' name really sucks as well - could we please make it something more obvious - like
SCHED_INTEL_TURBOor so - and similarly rename the file as well?
Quoted 3 lines
The
sched_intel_turbo.cfile could thus host all things related to scheduler support of turbo frequencies - it shouldn't be named after the Intel acronym of the day...
It would be nice to come up with such nitpicks during review. This thing went through 8 iterations, but nothing came up and I didn't mind the itmt naming.
Thanks,
tglx
Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
Quoted 12 lines · Thomas Gleixner
Quoted 10 lines · Ingo Molnar
Quoted 7 lines · tip-bot for Tim Chen
Commit-ID: 5e76b2ab36b40ca33023e78725bdc69eafd63134 Gitweb: http://git.kernel.org/tip/5e76b2ab36b40ca33023e78725bdc69eafd63134 Author: Tim Chen <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:55 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:19 +0100
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
x86: Enable Intel Turbo Boost Max Technology 3.0
This patch doesn't build:
Note that this patch has to be redone anyway, as it won't even build:
The branch where I merged it to builds fine.
Indeed you are right - asm/mutex.h is gone in locking/core, so this is a semantic merge conflict, not a build failure.
Quoted 26 lines
Though, yes I missed the
asm/mutex.hinclude which obviously should belinux/mutex.hQuoted 23 lines
arch/x86/kernel/itmt.c line 29
Quoted 7 lines
arch/x86/kernel/itmt.c new file +7
-0+#include <linux/sched.h> +#include <linux/cpumask.h> +#include <linux/cpuset.h> +#include <asm/mutex.h> +#include <linux/sched.h> +#include <linux/sysctl.h> +#include <linux/nodemask.h>
arch/x86/kernel/itmt.c:26:23: fatal error:asm/mutex.h: No such file or directoryarch/x86/Kconfig config SCHED_MC · line 949
Quoted 8 lines
arch/x86/Kconfig +8
-0+config SCHED_ITMT + bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + ---help--- + ITMT enabled scheduler support improves the CPU scheduler's decision + to move tasks to cpu core that can be boosted to a higher frequency + than others. It will have better performance at a cost of slightly + increased overhead in task migrations. If unsure say N here.Argh, so the 'itmt' name really sucks as well - could we please make it something more obvious - like
SCHED_INTEL_TURBOor so - and similarly rename the file as well?
Quoted 6 lines
Quoted 3 lines
The
sched_intel_turbo.cfile could thus host all things related to scheduler support of turbo frequencies - it shouldn't be named after the Intel acronym of the day...It would be nice to come up with such nitpicks during review. This thing went through 8 iterations, but nothing came up and I didn't mind the itmt naming.
Yeah, so I had to NAK an early iteration and didn't get around to doing a really detailed review yet - and after (falsely) thinking it had a build failure I got overly worked up about the bad naming: my bad and apologies!
So the code looks good to me but the naming still sucks a bit - I'm fine with having the commits re-merged as-is and renaming the Kconfig variable to something more expressive: I've done this in tip:sched/core and have fixed the asm/mutex.h thing as well.
Wrt. improving the naming:
Firstly, popular tech news has coined the 'Turbo Boost Max' technology 'TBM' (TBM2 and TBM3) as the natural acronym of the Intel feature - not 'ITMT'. So to anyone except people well aware of Intel acronyms the term 'ITMT' will be pretty meaningless.
Does something more generic like SCHED_MC_PRIO (as an extension to SCHED_MC) work with everyone? Intel Turbo Max 3.0 is the current (only) implementation of it, but I don't think the technology will stop at that stage as dies are getting larger but thinner.
I also think the Kconfig text is somewhat misleading and the default-disabled status is counterproductive:
+config SCHED_ITMT
+ bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + ---help--- + ITMT enabled scheduler support improves the CPU scheduler's decision + to move tasks to cpu core that can be boosted to a higher frequency + than others. It will have better performance at a cost of slightly + increased overhead in task migrations. If unsure say N here.
... the extra cost of smarter CPU selection is IMHO overwhelmed by the negative effects of not knowing about core frequency ordering, on most workloads.
A better default would be default-y I believe (that is what we do for CPU hardware enablement typically), and a better description would be something like:
+config SCHED_MC_PRIO
+ bool "CPU core priorities scheduler support"
+ depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE
+ default y
+ ---help---
+ Intel Turbo Boost Max 3.0 enabled CPUs have a core ordering determined at
+ manufacturing time, which allows certain cores to reach higher turbo
+ frequencies (when running single threaded workloads) than others.
+
+ Enabling this kernel feature teaches the scheduler about the TBM3 priority
+ order of the CPU cores and adjusts the scheduler's CPU selection logic
+ accordingly, so that higher overall system performance can be achieved.
+
+ This feature will have no effect on CPUs without this feature.
+
+ If unsure say Y here.
If/when other architectures make use of this the Kconfig entry can be moved into the scheduler Kconfig - but for the time being it can stay in arch/x86/.
Another variant would be to eliminate the Kconfig option altogether and make it a natural feature of SCHED_MC (like it is in the core scheduler).
Thanks,
Ingo
Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
Quoted 89 lines · Ingo Molnar
Quoted 26 lines · Thomas Gleixner
Quoted 24 lines
arch/x86/kernel/itmt.c line 29
Quoted 9 lines
arch/x86/kernel/itmt.c new file +7
-0+#include <linux/sched.h> +#include <linux/cpumask.h> +#include <linux/cpuset.h> +#include <asm/mutex.h> +#include <linux/sched.h> +#include <linux/sysctl.h> +#include <linux/nodemask.h>
arch/x86/kernel/itmt.c:26:23: fatal error:asm/mutex.h: No such file or directoryarch/x86/Kconfig config SCHED_MC · line 949
Quoted 9 lines
arch/x86/Kconfig +8
-0+config SCHED_ITMT + bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + ---help--- + ITMT enabled scheduler support improves the CPU scheduler's decision + to move tasks to cpu core that can be boosted to a higher frequency + than others. It will have better performance at a cost of slightly + increased overhead in task migrations. If unsure say N here.Argh, so the 'itmt' name really sucks as well - could we please make it something more obvious - like
SCHED_INTEL_TURBOor so - and similarly rename the file as well?Quoted 5 lines
Quoted 3 lines
The
sched_intel_turbo.cfile could thus host all things related to scheduler support of turbo frequencies - it shouldn't be named after the Intel acronym of the day...It would be nice to come up with such nitpicks during review. This thing went through 8 iterations, but nothing came up and I didn't mind the itmt naming.
Yeah, so I had to NAK an early iteration and didn't get around to doing a really detailed review yet - and after (falsely) thinking it had a build failure I got overly worked up about the bad naming: my bad and apologies!
So the code looks good to me but the naming still sucks a bit - I'm fine with having the commits re-merged as-is and renaming the
Kconfigvariable to something more expressive: I've done this in tip:sched/core and have fixed theasm/mutex.hthing as well.Wrt. improving the naming:
Firstly, popular tech news has coined the 'Turbo Boost Max' technology 'TBM' (TBM2 and TBM3) as the natural acronym of the Intel feature - not 'ITMT'. So to anyone except people well aware of Intel acronyms the term 'ITMT' will be pretty meaningless.
Does something more generic like
SCHED_MC_PRIO(as an extension toSCHED_MC) work with everyone? Intel Turbo Max 3.0 is the current (only) implementation of it, but I don't think the technology will stop at that stage as dies are getting larger but thinner.I also think the
Kconfigtext is somewhat misleading and the default-disabled status is counterproductive:+config
SCHED_ITMT
+ bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends onSCHED_MC&&CPU_SUP_INTEL&&X86_INTEL_PSTATE+ ---help---
+ ITMT enabled scheduler support improves the CPU scheduler's decision + to move tasks to cpu core that can be boosted to a higher frequency + than others. It will have better performance at a cost of slightly + increased overhead in task migrations. If unsure say N here.... the extra cost of smarter CPU selection is IMHO overwhelmed by the negative effects of not knowing about core frequency ordering, on most workloads.
A better default would be default-y I believe (that is what we do for CPU hardware enablement typically), and a better description would be something like:
(quoted diff) +16
-0+config SCHED_MC_PRIO + bool "CPU core priorities scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + default y + ---help--- + Intel Turbo Boost Max 3.0 enabled CPUs have a core ordering determined at + manufacturing time, which allows certain cores to reach higher turbo + frequencies (when running single threaded workloads) than others. + + Enabling this kernel feature teaches the scheduler about the TBM3 priority + order of the CPU cores and adjusts the scheduler's CPU selection logic + accordingly, so that higher overall system performance can be achieved. + + This feature will have no effect on CPUs without this feature. + + If unsure say Y here.
Quoted 6 lines
If/when other architectures make use of this the
Kconfigentry can be moved into the schedulerKconfig- but for the time being it can stay inarch/x86/.Another variant would be to eliminate the
Kconfigoption altogether and make it a natural feature ofSCHED_MC(like it is in the core scheduler).
I am fine with renaming SCHED_ITMT to SCHED_MC_PRIO. Patch 7 and 8 that Rafael merged into his tree also have SCHED_ITMT so they will need to be updated if we renamed it.
Thanks.
Tim
Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
Quoted 80 lines · Tim Chen
Quoted 79 lines · Ingo Molnar
Quoted 28 lines · Thomas Gleixner
Quoted 28 lines
arch/x86/kernel/itmt.c line 29
Quoted 9 lines
arch/x86/kernel/itmt.c new file +7
-0+#include <linux/sched.h> +#include <linux/cpumask.h> +#include <linux/cpuset.h> +#include <asm/mutex.h> +#include <linux/sched.h> +#include <linux/sysctl.h> +#include <linux/nodemask.h>
arch/x86/kernel/itmt.c:26:23: fatal error:asm/mutex.h: No such file or directory> > >arch/x86/Kconfig config SCHED_MC · line 949
Quoted 11 lines
arch/x86/Kconfig +5
-0+config SCHED_ITMT + bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + ---help--- + ITMT enabled scheduler support improves the CPU scheduler'sdecision
(quoted diff) +1
-0+ to move tasks to cpu core that can be boosted to a higherfrequency
(quoted diff) +1
-0+ than others. It will have better performance at a cost ofslightly
arch/x86/Kconfig +1
-0+ increased overhead in task migrations. If unsure say N here.Argh, so the 'itmt' name really sucks as well - could we please make it something more obvious - like
SCHED_INTEL_TURBOor so - and similarly rename the file as well?Quoted 7 lines
Quoted 3 lines
The
sched_intel_turbo.cfile could thus host all things related to scheduler support of turbo frequencies - it shouldn't be named after the Intel acronym of the day...It would be nice to come up with such nitpicks during review. This thing went through 8 iterations, but nothing came up and I didn't mind the itmt naming.>
Yeah, so I had to NAK an early iteration and didn't get around to doing a really detailed review yet - and after (falsely) thinking it had a build failure I got overly worked up about the bad naming: my bad and apologies!
So the code looks good to me but the naming still sucks a bit - I'm fine with having the commits re-merged as-is and renaming the
Kconfigvariable to something more expressive: I've done this in tip:sched/core and have fixed theasm/mutex.hthing as well.Wrt. improving the naming:
Firstly, popular tech news has coined the 'Turbo Boost Max' technology 'TBM' (TBM2 and TBM3) as the natural acronym of the Intel feature - not 'ITMT'. So to anyone except people well aware of Intel acronyms the term 'ITMT' will be pretty meaningless.
Does something more generic like
SCHED_MC_PRIO(as an extension toSCHED_MC) work with everyone? Intel Turbo Max 3.0 is the current (only) implementation of it, but I don't think the technology will stop at that stage as dies are getting larger but thinner.I also think the
Kconfigtext is somewhat misleading and the default-disabled status is counterproductive:arch/x86/Kconfig +5
-0+config SCHED_ITMT + bool "Intel Turbo Boost Max Technology (ITMT) scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + ---help--- + ITMT enabled scheduler support improves the CPU scheduler'sdecision + to move tasks to cpu core that can be boosted to a
higher frequency + than others. It will have better performance
at a cost of slightly + increased overhead in task migrations. If
unsure say N here.... the extra cost of smarter CPU selection is IMHO overwhelmed by the negative effects of not knowing about core frequency ordering, on most workloads.
A better default would be default-y I believe (that is what we do for CPU hardware enablement typically), and a better description would be something like:
Quoted 7 lines
Quoted 7 lines
(quoted diff) +6
-0+config SCHED_MC_PRIO + bool "CPU core priorities scheduler support" + depends on SCHED_MC && CPU_SUP_INTEL && X86_INTEL_PSTATE + default y + ---help--- + Intel Turbo Boost Max 3.0 enabled CPUs have a core orderingdetermined at + manufacturing time, which allows certain cores to
reach
Quoted 5 lines
Quoted 5 lines
higher turbo + frequencies (when running single threaded workloads) than
others. +(quoted diff) +1
-0+ Enabling this kernel feature teaches the scheduler about the TBM3priority + order of the CPU cores and adjusts the scheduler's CPU
selection logic + accordingly, so that higher overall system
performance
Quoted 9 lines
Quoted 9 lines
can be achieved. +
(quoted diff) +3
-0+ This feature will have no effect on CPUs without this feature. + + If unsure say Y here.If/when other architectures make use of this the
Kconfigentry can be moved into the schedulerKconfig- but for the time being it can stay inarch/x86/.
Quoted 7 lines
Quoted 3 lines
Another variant would be to eliminate the
Kconfigoption altogether and make it a natural feature ofSCHED_MC(like it is in the core scheduler).I am fine with renaming
SCHED_ITMTtoSCHED_MC_PRIO. Patch 7 and 8 that Rafael merged into his tree also haveSCHED_ITMTso they will need to be updated if we renamed it.
No, I haven't. They are in tip AFAICS.
Thanks,
Rafael
Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
In reply to Tim ChenQuoted 10 lines · Tim Chen
Quoted 8 lines
(quoted diff) +1
-0+ If unsure say Y here.If/when other architectures make use of this the
Kconfigentry can be moved into the schedulerKconfig- but for the time being it can stay inarch/x86/.Another variant would be to eliminate the
Kconfigoption altogether and make it a natural feature ofSCHED_MC(like it is in the core scheduler).I am fine with renaming
SCHED_ITMTtoSCHED_MC_PRIO.
Ok, could you please send a delta patch on top of tip:sched/core that does this and the other improvements?
Thanks,
Ingo
Re: [tip:x86/core] x86: Enable Intel Turbo Boost Max Technology 3.0
Quoted 9 lines · Ingo Molnar
Quoted 7 lines · Tim Chen
Quoted 7 lines
(quoted diff) +1
-0+ If unsure say Y here.If/when other architectures make use of this the
Kconfigentry can be moved into the schedulerKconfig- but for the time being it can stay inarch/x86/.
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
Another variant would be to eliminate the
Kconfigoption altogether and make it a natural feature ofSCHED_MC(like it is in the core scheduler).I am fine with renaming
SCHED_ITMTtoSCHED_MC_PRIO.Ok, could you please send a delta patch on top of tip:sched/core that does this and the other improvements?
I have sent a delta patch in a separate mail for this change.
Thanks.
Tim
PATCH v8 4/8 x86/sysctl: Add sysctl for ITMT scheduling feature
In reply to Tim ChenIntel Turbo Boost Max Technology 3.0 (ITMT) feature allows some cores to be boosted to higher turbo frequency than others.
Add /proc/sys/kernel/sched_itmt_enabled so operator can enable/disable scheduling of tasks that favor cores with higher turbo boost frequency potential.
By default, system that is ITMT capable and single socket has this feature turned on. It is more likely to be lightly loaded and operates in Turbo range.
When there is a change in the ITMT scheduling operation desired, a rebuild of the sched domain is initiated so the scheduler can set up sched domains with appropriate flag to enable/disable ITMT scheduling operations.
--- arch/x86/include/asm/topology.h | 7 ++- arch/x86/kernel/itmt.c | 108 +++++++++++++++++++++++++++++++++++++++- 2 files changed, 112 insertions(+), 3 deletions(-)
arch/x86/include/asm/topology.h +5 -2
@@ -152,23 +152,26 @@ extern bool x86_topology_update;#include <asm/percpu.h> DECLARE_PER_CPU_READ_MOSTLY (int, sched_core_priority); +extern unsigned int __read_mostly sysctl_sched_itmt_enabled;/* Interface to set priority of a cpu */ void sched_set_itmt_core_prio (int prio,int core_cpu);/* Interface to notify scheduler that system supports ITMT */ -void sched_set_itmt_support (void ); +int sched_set_itmt_support (void );/* Interface to notify scheduler that system revokes ITMT support */ void sched_clear_itmt_support (void );#else /* CONFIG_SCHED_ITMT */ +#define sysctl_sched_itmt_enabled 0static inline void sched_set_itmt_core_prio (int prio,int core_cpu) { } -static inline void sched_set_itmt_support (void ) +static inline int sched_set_itmt_support (void ) { +return 0 ; }static inline void sched_clear_itmt_support (void ) {
arch/x86/kernel/itmt.c +107 -1
140 lines not on this page · raw message
Signature · 1 line
2.5.5
tip-bot for Tim Chen
merge bot[tip:x86/core] x86/sysctl: Add sysctl for ITMT scheduling feature
x86/sysctl: Add sysctl for ITMT scheduling feature
Commit-ID: f9793e34952cda133caaa35738a4b46053331c96 Gitweb: http://git.kernel.org/tip/f9793e34952cda133caaa35738a4b46053331c96 Author: Tim Chen <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:56 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:19 +0100
x86/sysctl: Add sysctl for ITMT scheduling feature
Intel Turbo Boost Max Technology 3.0 (ITMT) feature allows some cores to be boosted to higher turbo frequency than others.
Add /proc/sys/kernel/sched_itmt_enabled so operator can enable/disable scheduling of tasks that favor cores with higher turbo boost frequency potential.
By default, system that is ITMT capable and single socket has this feature turned on. It is more likely to be lightly loaded and operates in Turbo range.
When there is a change in the ITMT scheduling operation desired, a rebuild of the sched domain is initiated so the scheduler can set up sched domains with appropriate flag to enable/disable ITMT scheduling operations.
--- arch/x86/include/asm/topology.h | 7 ++- arch/x86/kernel/itmt.c | 108 +++++++++++++++++++++++++++++++++++++++- 2 files changed, 112 insertions(+), 3 deletions(-)
arch/x86/include/asm/topology.h +5 -2
@@ -152,23 +152,26 @@ extern bool x86_topology_update;#include <asm/percpu.h> DECLARE_PER_CPU_READ_MOSTLY (int, sched_core_priority); +extern unsigned int __read_mostly sysctl_sched_itmt_enabled;/* Interface to set priority of a cpu */ void sched_set_itmt_core_prio (int prio,int core_cpu);/* Interface to notify scheduler that system supports ITMT */ -void sched_set_itmt_support (void ); +int sched_set_itmt_support (void );/* Interface to notify scheduler that system revokes ITMT support */ void sched_clear_itmt_support (void );#else /* CONFIG_SCHED_ITMT */ +#define sysctl_sched_itmt_enabled 0static inline void sched_set_itmt_core_prio (int prio,int core_cpu) { } -static inline void sched_set_itmt_support (void ) +static inline int sched_set_itmt_support (void ) { +return 0 ; }static inline void sched_clear_itmt_support (void ) {
arch/x86/kernel/itmt.c +107 -1
140 lines not on this page · raw message
Re: [PATCH v8 4/8] x86/sysctl: Add sysctl for ITMT scheduling feature
In reply to Tim ChenQuoted 24 lines · Tim Chen
Intel Turbo Boost Max Technology 3.0 (ITMT) feature allows some cores to be boosted to higher turbo frequency than others.
Add
/proc/sys/kernel/sched_itmt_enabledso operator can enable/disable scheduling of tasks that favor cores with higher turbo boost frequency potential.By default, system that is ITMT capable and single socket has this feature turned on. It is more likely to be lightly loaded and operates in Turbo range.
When there is a change in the ITMT scheduling operation desired, a rebuild of the sched domain is initiated so the scheduler can set up sched domains with appropriate flag to enable/disable ITMT scheduling operations.
Co-developed-by Peter Zijlstra (Intel) <[email protected]>Co-developed-by Srinivas Pandruvada <[email protected]>Signed-off-by Tim Chen <[email protected]>--- arch/x86/include/asm/topology.h | 7 ++- arch/x86/kernel/itmt.c | 108 +++++++++++++++++++++++++++++++++++++++- 2 files changed, 112 insertions(+), 3 deletions(-)
...
arch/x86/kernel/itmt.c DEFINE_PER_CPU_READ_MOSTLY(int, sched_core_priority); · line 44
Quoted 8 lines
arch/x86/kernel/itmt.c +8
-0+/* +* Boolean to control whether we want to move processes to cpu capable +* of higher turbo frequency for cpus supporting Intel Turbo Boost Max +* Technology 3.0. +* +* It can be set via /proc/sys/kernel/sched_itmt_enabled +*/ +unsigned int __read_mostly sysctl_sched_itmt_enabled;
Err, can we not have the boolean in the name itself?
I.e., have it called sysctl_sched_itmt and 1 means enabled and 0 disabled? I.e., the classic thing. :)
Ditto for the sysctl name?
Signature · 5 lines
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- Re: [PATCH v8 4/8] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 39 lines · Borislav Petkov
Quoted 25 lines · Tim Chen
Intel Turbo Boost Max Technology 3.0 (ITMT) feature allows some cores to be boosted to higher turbo frequency than others.
Add
/proc/sys/kernel/sched_itmt_enabledso operator can enable/disable scheduling of tasks that favor cores with higher turbo boost frequency potential.By default, system that is ITMT capable and single socket has this feature turned on. It is more likely to be lightly loaded and operates in Turbo range.
When there is a change in the ITMT scheduling operation desired, a rebuild of the sched domain is initiated so the scheduler can set up sched domains with appropriate flag to enable/disable ITMT scheduling operations.
Co-developed-by Peter Zijlstra (Intel) <[email protected]>Co-developed-by Srinivas Pandruvada <[email protected]>Signed-off-by Tim Chen <[email protected]>---
arch/x86/include/asm/topology.h | 7 ++-
arch/x86/kernel/itmt.c | 108 +++++++++++++++++++++++++++++++++++++++-2 files changed, 112 insertions(+), 3 deletions(-)...
arch/x86/kernel/itmt.c DEFINE_PER_CPU_READ_MOSTLY(int, sched_core_priority); · line 44
Quoted 9 lines
arch/x86/kernel/itmt.c +8
-0+/* +* Boolean to control whether we want to move processes to cpu capable +* of higher turbo frequency for cpus supporting Intel Turbo Boost Max +* Technology 3.0. +* +* It can be set via /proc/sys/kernel/sched_itmt_enabled +*/ sched_autogroup_enabled +unsigned int __read_mostly sysctl_sched_itmt_enabled;Err, can we not have the boolean in the name itself?
Quoted 4 lines
I.e., have it called
sysctl_sched_itmtand 1 means enabled and 0 disabled? I.e., the classic thing. :)Ditto for the sysctl name?
I am following the convention in /proc/sys/kernel/sched_autogroup_enabled and sysctl_sched_autogroup_enabled that's also in /proc/sys/kernel.
Thanks.
Tim
Re: [PATCH v8 4/8] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 2 lines · Tim Chen
I am following the convention in
/proc/sys/kernel/sched_autogroup_enabledand sysctl_sched_autogroup_enabled that's also in/proc/sys/kernel.
That's hardly a convention to me:
$ ls -l /proc/sys/kernel/*abled -rw-r--r-- 1 root root 0 Nov 29 18:47 /proc/sys/kernel/ftrace_enabled -rw-r--r-- 1 root root 0 Nov 29 18:47 /proc/sys/kernel/kexec_load_disabled -rw-r--r-- 1 root root 0 Nov 29 18:47 /proc/sys/kernel/modules_disabled
enabled, disabled, ...
Signature · 5 lines
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- PATCH v8 5/8 x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU
In reply to Tim ChenSome Intel cores in a package can be boosted to a higher turbo frequency with ITMT 3.0 technology. The scheduler can use the asymmetric packing feature to move tasks to the more capable cores.
If ITMT is enabled, add SD_ASYM_PACKING flag to the thread and core sched domains to enable asymmetric packing.
--- arch/x86/kernel/smpboot.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
arch/x86/kernel/smpboot.c +24 -4
@@ -482,22 +482,42 @@ static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)return false; } +#if defined(CONFIG_SCHED_SMT ) || defined(CONFIG_SCHED_MC ) +static inline int x86_sched_itmt_flags (void ) +{ +return sysctl_sched_itmt_enabled ?SD_ASYM_PACKING :0 ; +} + +#ifdef CONFIG_SCHED_MC +static int x86_core_flags (void ) +{ +return cpu_core_flags () |x86_sched_itmt_flags (); +} +#endif +#ifdef CONFIG_SCHED_SMT +static int x86_smt_flags (void ) +{ +return cpu_smt_flags () |x86_sched_itmt_flags (); +} +#endif +#endif +static struct sched_domain_topology_level x86_numa_in_package_topology[] = { #ifdef CONFIG_SCHED_SMT - { cpu_smt_mask, cpu_smt_flags,SD_INIT_NAME (SMT ) }, + { cpu_smt_mask, x86_smt_flags,SD_INIT_NAME (SMT ) }, #endif #ifdef CONFIG_SCHED_MC - { cpu_coregroup_mask, cpu_core_flags,SD_INIT_NAME (MC ) }, + { cpu_coregroup_mask, x86_core_flags,SD_INIT_NAME (MC ) }, #endif {NULL , }, };static struct sched_domain_topology_level x86_topology[] = { #ifdef CONFIG_SCHED_SMT - { cpu_smt_mask, cpu_smt_flags,SD_INIT_NAME (SMT ) }, + { cpu_smt_mask, x86_smt_flags,SD_INIT_NAME (SMT ) }, #endif #ifdef CONFIG_SCHED_MC - { cpu_coregroup_mask, cpu_core_flags,SD_INIT_NAME (MC ) }, + { cpu_coregroup_mask, x86_core_flags,SD_INIT_NAME (MC ) }, #endif { cpu_cpu_mask,SD_INIT_NAME (DIE ) }, {NULL , },
Signature · 1 line
2.5.5
tip-bot for Tim Chen
merge bot[tip:x86/core] x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU
x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU
Commit-ID: d3d37d850d1d77bd66bceb8326e6353d3314b270 Gitweb: http://git.kernel.org/tip/d3d37d850d1d77bd66bceb8326e6353d3314b270 Author: Tim Chen <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:57 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:20 +0100
x86/sched: Add SD_ASYM_PACKING flags to x86 ITMT CPU
Some Intel cores in a package can be boosted to a higher turbo frequency with ITMT 3.0 technology. The scheduler can use the asymmetric packing feature to move tasks to the more capable cores.
If ITMT is enabled, add SD_ASYM_PACKING flag to the thread and core sched domains to enable asymmetric packing.
--- arch/x86/kernel/smpboot.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
arch/x86/kernel/smpboot.c +24 -4
@@ -482,22 +482,42 @@ static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)return false; } +#if defined(CONFIG_SCHED_SMT ) || defined(CONFIG_SCHED_MC ) +static inline int x86_sched_itmt_flags (void ) +{ +return sysctl_sched_itmt_enabled ?SD_ASYM_PACKING :0 ; +} + +#ifdef CONFIG_SCHED_MC +static int x86_core_flags (void ) +{ +return cpu_core_flags () |x86_sched_itmt_flags (); +} +#endif +#ifdef CONFIG_SCHED_SMT +static int x86_smt_flags (void ) +{ +return cpu_smt_flags () |x86_sched_itmt_flags (); +} +#endif +#endif +static struct sched_domain_topology_level x86_numa_in_package_topology[] = { #ifdef CONFIG_SCHED_SMT - { cpu_smt_mask, cpu_smt_flags,SD_INIT_NAME (SMT ) }, + { cpu_smt_mask, x86_smt_flags,SD_INIT_NAME (SMT ) }, #endif #ifdef CONFIG_SCHED_MC - { cpu_coregroup_mask, cpu_core_flags,SD_INIT_NAME (MC ) }, + { cpu_coregroup_mask, x86_core_flags,SD_INIT_NAME (MC ) }, #endif {NULL , }, };static struct sched_domain_topology_level x86_topology[] = { #ifdef CONFIG_SCHED_SMT - { cpu_smt_mask, cpu_smt_flags,SD_INIT_NAME (SMT ) }, + { cpu_smt_mask, x86_smt_flags,SD_INIT_NAME (SMT ) }, #endif #ifdef CONFIG_SCHED_MC - { cpu_coregroup_mask, cpu_core_flags,SD_INIT_NAME (MC ) }, + { cpu_coregroup_mask, x86_core_flags,SD_INIT_NAME (MC ) }, #endif { cpu_cpu_mask,SD_INIT_NAME (DIE ) }, {NULL , },
PATCH v8 6/8 acpi: bus: Enable HWP CPPC objects
In reply to Tim ChenFrom: Srinivas Pandruvada <[email protected]>
Need to set platform wide _OSC bits to enable CPPC and CPPC version 2. If platform supports CPPC, then BIOS exposes CPPC tables.
The primary reason to enable CPPC support is to get the maximum performance of each CPU to check and enable Intel Turbo Boost Max Technology 3.0 (ITMT).
--- drivers/acpi/bus.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/acpi/bus.c +7 -0
@@ -331,6 +331,13 @@ static void acpi_bus_osc_support(void) capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_HOTPLUG_OST_SUPPORT ; capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_PCLPI_SUPPORT ; +#ifdef CONFIG_X86 +if (boot_cpu_has (X86_FEATURE_HWP )) { + capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_CPC_SUPPORT ; + capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_CPCV2_SUPPORT ; + } +#endif +if (!ghes_disable) capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_APEI_SUPPORT ;if (ACPI_FAILURE (acpi_get_handle (NULL ,"\\_SB" , &handle)))
Signature · 1 line
2.5.5
tip-bot for Srinivas Pandruvada
merge bot[tip:x86/core] acpi/bus: Enable HWP CPPC objects
acpi/bus: Enable HWP CPPC objects
Commit-ID: 5c2832e91a3ed45f35531ae1c5afba8eac22c81f Gitweb: http://git.kernel.org/tip/5c2832e91a3ed45f35531ae1c5afba8eac22c81f Author: Srinivas Pandruvada <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:58 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:20 +0100
acpi/bus: Enable HWP CPPC objects
Need to set platform wide _OSC bits to enable CPPC and CPPC version 2. If platform supports CPPC, then BIOS exposes CPPC tables.
The primary reason to enable CPPC support is to get the maximum performance of each CPU to check and enable Intel Turbo Boost Max Technology 3.0 (ITMT).
--- drivers/acpi/bus.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/acpi/bus.c +7 -0
@@ -331,6 +331,13 @@ static void acpi_bus_osc_support(void) capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_HOTPLUG_OST_SUPPORT ; capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_PCLPI_SUPPORT ; +#ifdef CONFIG_X86 +if (boot_cpu_has (X86_FEATURE_HWP )) { + capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_CPC_SUPPORT ; + capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_CPCV2_SUPPORT ; + } +#endif +if (!ghes_disable) capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_APEI_SUPPORT ;if (ACPI_FAILURE (acpi_get_handle (NULL ,"\\_SB" , &handle)))
PATCH v8 7/8 acpi: bus: Set _OSC for diverse core support
In reply to Tim ChenFrom: Srinivas Pandruvada <[email protected]>
Set the OSC_SB_CPC_DIVERSE_HIGH_SUPPORT (bit 12) to enable diverse core support.
This is required to inform BIOS the support of Intel Turbo Boost Max Technology 3.0 feature.
--- drivers/acpi/bus.c | 3 +++ include/linux/acpi.h | 1 + 2 files changed, 4 insertions(+)
drivers/acpi/bus.c +3 -0
@@ -338,6 +338,9 @@ static void acpi_bus_osc_support(void) }#endif +if (IS_ENABLED (CONFIG_SCHED_ITMT )) + capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_CPC_DIVERSE_HIGH_SUPPORT ; +if (!ghes_disable) capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_APEI_SUPPORT ;if (ACPI_FAILURE (acpi_get_handle (NULL ,"\\_SB" , &handle)))
include/linux/acpi.h +1 -0
@@ -469,6 +469,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);#define OSC_SB_CPCV2_SUPPORT 0x00000040#define OSC_SB_PCLPI_SUPPORT 0x00000080#define OSC_SB_OSLPI_SUPPORT 0x00000100 +#define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT 0x00001000extern bool osc_sb_apei_support_acked;extern bool osc_pc_lpi_support_confirmed;
Signature · 1 line
2.5.5
tip-bot for Srinivas Pandruvada
merge bot[tip:x86/core] acpi/bus: Set _OSC for diverse core support
acpi/bus: Set _OSC for diverse core support
Commit-ID: 8b533a0eeefc5861cea57163dd3cec2798a77f6c Gitweb: http://git.kernel.org/tip/8b533a0eeefc5861cea57163dd3cec2798a77f6c Author: Srinivas Pandruvada <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:23:59 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:20 +0100
acpi/bus: Set _OSC for diverse core support
Set the OSC_SB_CPC_DIVERSE_HIGH_SUPPORT (bit 12) to enable diverse core support.
This is required to enable the BIOS support of the Intel Turbo Boost Max Technology 3.0 feature.
--- drivers/acpi/bus.c | 3 +++ include/linux/acpi.h | 1 + 2 files changed, 4 insertions(+)
drivers/acpi/bus.c +3 -0
@@ -338,6 +338,9 @@ static void acpi_bus_osc_support(void) }#endif +if (IS_ENABLED (CONFIG_SCHED_ITMT )) + capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_CPC_DIVERSE_HIGH_SUPPORT ; +if (!ghes_disable) capbuf[OSC_SUPPORT_DWORD ] |=OSC_SB_APEI_SUPPORT ;if (ACPI_FAILURE (acpi_get_handle (NULL ,"\\_SB" , &handle)))
include/linux/acpi.h +1 -0
@@ -469,6 +469,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);#define OSC_SB_CPCV2_SUPPORT 0x00000040#define OSC_SB_PCLPI_SUPPORT 0x00000080#define OSC_SB_OSLPI_SUPPORT 0x00000100 +#define OSC_SB_CPC_DIVERSE_HIGH_SUPPORT 0x00001000extern bool osc_sb_apei_support_acked;extern bool osc_pc_lpi_support_confirmed;
PATCH v8 8/8 cpufreq: intel_pstate: Use CPPC to get max performance
In reply to Tim ChenFrom: "Rafael J. Wysocki" <[email protected]>
This change uses acpi cppc_lib interface to get CPPC performance limits and calls scheduler interface to update per cpu highest priority. If there is a difference in highest performance of each CPUs, call scheduler interface to enable ITMT feature for only one time.
Here sched_set_itmt_core_prio() is called to set priorities and sched_set_itmt_support() is called to enable ITMT feature.
--- drivers/cpufreq/Kconfig.x86 | 1 + drivers/cpufreq/intel_pstate.c | 56 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 56 insertions(+), 1 deletion(-)
drivers/cpufreq/Kconfig.x86 +1 -0
@@ -6,6 +6,7 @@ config X86_INTEL_PSTATE bool "Intel P state control" depends on X86 select ACPI_PROCESSOR if ACPI + select ACPI_CPPC_LIB if X86_64 && ACPI && SCHED_ITMT help This driver provides a P state for Intel core processors. The driver implements an internal governor and will become
drivers/cpufreq/intel_pstate.c +55 -1
75 lines not on this page · raw message
Signature · 1 line
2.5.5
tip-bot for Rafael J. Wysocki
merge bot[tip:x86/core] cpufreq/intel_pstate: Use CPPC to get max performance
cpufreq/intel_pstate: Use CPPC to get max performance
Commit-ID: 17669006adf64d35a74cb21e3c8dfb6fb8be689f Gitweb: http://git.kernel.org/tip/17669006adf64d35a74cb21e3c8dfb6fb8be689f Author: Rafael J. Wysocki <[email protected]> AuthorDate: Tue, 22 Nov 2016 12:24:00 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Thu, 24 Nov 2016 20:44:20 +0100
cpufreq/intel_pstate: Use CPPC to get max performance
Use the acpi cppc_lib interface to get CPPC performance limits and update the per cpu priority for the ITMT scheduler. If the highest performance of CPUs differs the ITMT feature is enabled.
--- drivers/cpufreq/Kconfig.x86 | 1 + drivers/cpufreq/intel_pstate.c | 56 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 56 insertions(+), 1 deletion(-)
drivers/cpufreq/Kconfig.x86 +1 -0
@@ -6,6 +6,7 @@ config X86_INTEL_PSTATE bool "Intel P state control" depends on X86 select ACPI_PROCESSOR if ACPI + select ACPI_CPPC_LIB if X86_64 && ACPI && SCHED_ITMT help This driver provides a P state for Intel core processors. The driver implements an internal governor and will become
drivers/cpufreq/intel_pstate.c +55 -1
75 lines not on this page · raw message
Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance
In reply to Tim ChenQuoted 9 lines · Tim Chen
From: "Rafael J. Wysocki" <[email protected]>
This change uses acpi
cppc_libinterface to get CPPC performance limits and calls scheduler interface to update per cpu highest priority. If there is a difference in highest performance of each CPUs, call scheduler interface to enable ITMT feature for only one time.Here
sched_set_itmt_core_prio()is called to set priorities andsched_set_itmt_support()is called to enable ITMT feature.
First I had crashed what I bisected down to de966cf4a4fa ("sched/x86: Change CONFIG_SCHED_ITMT to CONFIG_SCHED_MC_PRIO") because it made SCHED_ITMT the default.
Then I run another bisect round and got here with the same backtrace:
|BUG: unable to handle kernel NULL pointer dereference at (null) |IP: [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 |PGD 0 [ 0.577616] |Oops: 0000 [#1] SMP |Modules linked in: |CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc6-00146-g17669006adf6 #51 |task: ffff88003f878000 task.stack: ffffc90000008000 |RIP: 0010:[<ffffffff812aab6e>] [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 |RSP: 0000:ffffc9000000bd48 EFLAGS: 00010296 |RAX: 00000000000137e0 RBX: 0000000000000000 RCX: 0000000000000001 |RDX: ffff88003fc00000 RSI: 0000000000000000 RDI: ffff88003fbca130 |RBP: ffffc9000000bd60 R08: 0000000000000514 R09: 0000000000000000 |R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002 |R13: 0000000000000020 R14: ffffffff8167cb00 R15: 0000000000000000 |FS: 0000000000000000(0000) GS:ffff88003fcc0000(0000) knlGS:0000000000000000 |CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 |CR2: 0000000000000000 CR3: 0000000001618000 CR4: 00000000000406e0 |Stack: | ffff88003f939848 ffff88003fbca130 0000000000000001 ffffc9000000bd80 | ffffffff812a4ccb ffff88003fc0cee8 0000000000000000 ffffc9000000bdb8 | ffffffff812dc20d ffff88003fc0cee8 ffffffff8167cb00 ffff88003fc0cf48 |Call Trace: | [<ffffffff812a4ccb>] acpi_processor_stop+0xb2/0xc5 | [<ffffffff812dc20d>] driver_probe_device+0x14d/0x2f0 | [<ffffffff812dc41e>] __driver_attach+0x6e/0x90 | [<ffffffff812da234>] bus_for_each_dev+0x54/0x90 | [<ffffffff812dbbf9>] driver_attach+0x19/0x20 | [<ffffffff812db6a6>] bus_add_driver+0xe6/0x200 | [<ffffffff812dcb23>] driver_register+0x83/0xc0 | [<ffffffff816f050a>] acpi_processor_driver_init+0x20/0x94 | [<ffffffff81000487>] do_one_initcall+0x97/0x180 | [<ffffffff816ccf5c>] kernel_init_freeable+0x112/0x1a6 | [<ffffffff813a0fc9>] kernel_init+0x9/0xf0 | [<ffffffff813acf35>] ret_from_fork+0x25/0x30 |Code: 02 00 00 00 48 8b 14 d5 e0 c3 55 81 48 8b 1c 02 4c 8d 6b 20 eb 15 49 8b 7d 00 48 85 ff 74 05 e8 39 8c d9 ff 41 ff c4 49 83 c5 20 <44> 3b 23 72 e6 48 8d bb a0 02 00 00 e8 b1 6f f9 ff 48 89 df e8 |RIP [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 | RSP <ffffc9000000bd48> |CR2: 0000000000000000 |---[ end trace 917a625107b09711 ]---
The patch attached fixes it. Could someone who looked longer at the code than I actually confirm that this fine or fix it differently? This makes the crash on boot on a "default" kvm setup go away.
--- drivers/acpi/cppc_acpi.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/acpi/cppc_acpi.c +3 -0
@@ -803,6 +803,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)if (addr)iounmap (addr); } +per_cpu (cpc_desc_ptr, pr->id) =NULL ;kfree (cpc_ptr); out_buf_free:
@@ -824,6 +825,8 @@ void acpi_cppc_processor_exit(struct acpi_processor *pr)void __iomem *addr; cpc_ptr =per_cpu (cpc_desc_ptr, pr->id); +if (!cpc_ptr) +return ;/* Free all the mapped sys mem areas for this CPU */ for (i =2 ; i < cpc_ptr->num_entries; i++) {
Signature · 1 line
2.11.0
Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance
Quoted 23 lines · Sebastian Andrzej Siewior
Signed-off-by Sebastian Andrzej Siewior <[email protected]>---
drivers/acpi/cppc_acpi.c | 3 +++1 file changed, 3 insertions(+)drivers/acpi/cppc_acpi.c +1
-0@@ -803,6 +803,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) if (addr) iounmap(addr); } +per_cpu (cpc_desc_ptr, pr->id) =NULL ; kfree(cpc_ptr);
out_buf_free:drivers/acpi/cppc_acpi.c +0
-0@@ -824,6 +825,8 @@ void acpi_cppc_processor_exit(struct acpi_processor *pr) void __iomem *addr;
cpc_ptr=per_cpu(cpc_desc_ptr, pr->id);
drivers/acpi/cppc_acpi.c void acpi_cppc_processor_exit(struct acpi_processor *pr) · line 829
Quoted 2 lines
drivers/acpi/cppc_acpi.c +2
-0+if (!cpc_ptr) +return ;
I agree that not handling null pointer here is a bug that should be fixed. The cpc_ptr is checked at other places like acpi_get_psd_map. We could potentially have a null cpc_ptr say when
the parsing of CPC table failed. We should handle such cases gracefully.
Tim
Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance
Quoted 23 lines · Tim Chen
Quoted 22 lines · Sebastian Andrzej Siewior
Signed-off-by Sebastian Andrzej Siewior <[email protected]>--- drivers/acpi/cppc_acpi.c | 3 +++ 1 file changed, 3 insertions(+)drivers/acpi/cppc_acpi.c +1
-0@@ -803,6 +803,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)if (addr)iounmap (addr); } +per_cpu (cpc_desc_ptr, pr->id) =NULL ;kfree (cpc_ptr); out_buf_free:@@ -824,6 +825,8 @@ void acpi_cppc_processor_exit(struct acpi_processor *pr)void __iomem *addr;
Quoted 8 lines
drivers/acpi/cppc_acpi.c void acpi_cppc_processor_exit(struct acpi_processor *pr) · line 829
Quoted 3 lines
drivers/acpi/cppc_acpi.c +2
-0cpc_ptr =per_cpu (cpc_desc_ptr, pr->id); +if (!cpc_ptr) +return ;I agree that not handling null pointer here is a bug that should be fixed. The
cpc_ptris checked at other places likeacpi_get_psd_map. We could potentially have a nullcpc_ptrsay when
the parsing of CPC table failed. We should handle such cases gracefully.
Agreed, but the bug fixed by the first hunk is real too. I'd fix it a bit differently, though:
--- drivers/acpi/cppc_acpi.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/acpi/cppc_acpi.c +8 -4
@@ -776,9 +776,6 @@ int acpi_cppc_processor_probe(struct acpinit_waitqueue_head (&pcc_data.pcc_write_wait_q); } -/* Plug PSD data into this CPUs CPC descriptor. */ -per_cpu (cpc_desc_ptr, pr->id) = cpc_ptr; -/* Everything looks okay */ pr_debug ("Parsed CPC struct for CPU: %d\n" , pr->id);
@@ -789,10 +786,15 @@ int acpi_cppc_processor_probe(struct acp goto out_free; } +/* Plug PSD data into this CPUs CPC descriptor. */ +per_cpu (cpc_desc_ptr, pr->id) = cpc_ptr; + ret =kobject_init_and_add (&cpc_ptr->kobj, &cppc_ktype, &cpu_dev->kobj,"acpi_cppc" ); -if (ret) +if (ret) { +per_cpu (cpc_desc_ptr, pr->id) =NULL ; goto out_free; + }kfree (output.pointer);return 0 ;
@@ -826,6 +828,8 @@ void acpi_cppc_processor_exit(struct acpvoid __iomem *addr; cpc_ptr =per_cpu (cpc_desc_ptr, pr->id); +if (!cpc_ptr) +return ;/* Free all the mapped sys mem areas for this CPU */ for (i =2 ; i < cpc_ptr->num_entries; i++) {
Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance
Quoted 4 lines · Rafael J. Wysocki
Agreed, but the bug fixed by the first hunk is real too. I'd fix it a bit differently, though:
Tentatively-signed-off-by Rafael J. Wysocki <[email protected]>
Is there anything you want me to do here? The hunk in acpi_cppc_processor_exit() is unchanged and is the one that led to the crash. The other hunk I made (the one you changed) was something I noticed while looking at the code - nothing that hit me directly.
Sebastian
Rafael J. Wysocki
maintainerRe: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance
Quoted 10 lines · Sebastian Andrzej Siewior
Quoted 4 lines · Rafael J. Wysocki
Agreed, but the bug fixed by the first hunk is real too. I'd fix it a bit differently, though:
Tentatively-signed-off-by Rafael J. Wysocki <[email protected]>Is there anything you want me to do here? The hunk in
acpi_cppc_processor_exit()is unchanged and is the one that led to the crash. The other hunk I made (the one you changed) was something I noticed while looking at the code - nothing that hit me directly.
OK, thanks.
I'll add a changelog to the patch and resend it later today.
Thanks,
Rafael
PATCH 1/1 ACPI / CPPC: Fix per-CPU pointers management
From: Rafael J. Wysocki <[email protected]>
Enabling ACPI CPPC on x86 causes a NULL pointer dereference to occur (on boot on a "default" KVM setup) in acpi_cppc_processor_exit() due to a missing check against NULL in there:
|BUG: unable to handle kernel NULL pointer dereference at (null) |IP: [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 |PGD 0 [ 0.577616] |Oops: 0000 [#1] SMP |Modules linked in: |CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc6-00146-g17669006adf6 #51 |task: ffff88003f878000 task.stack: ffffc90000008000 |RIP: 0010:[<ffffffff812aab6e>] [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 |RSP: 0000:ffffc9000000bd48 EFLAGS: 00010296 |RAX: 00000000000137e0 RBX: 0000000000000000 RCX: 0000000000000001 |RDX: ffff88003fc00000 RSI: 0000000000000000 RDI: ffff88003fbca130 |RBP: ffffc9000000bd60 R08: 0000000000000514 R09: 0000000000000000 |R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002 |R13: 0000000000000020 R14: ffffffff8167cb00 R15: 0000000000000000 |FS: 0000000000000000(0000) GS:ffff88003fcc0000(0000) knlGS:0000000000000000 |CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 |CR2: 0000000000000000 CR3: 0000000001618000 CR4: 00000000000406e0 |Stack: | ffff88003f939848 ffff88003fbca130 0000000000000001 ffffc9000000bd80 | ffffffff812a4ccb ffff88003fc0cee8 0000000000000000 ffffc9000000bdb8 | ffffffff812dc20d ffff88003fc0cee8 ffffffff8167cb00 ffff88003fc0cf48 |Call Trace: | [<ffffffff812a4ccb>] acpi_processor_stop+0xb2/0xc5 | [<ffffffff812dc20d>] driver_probe_device+0x14d/0x2f0 | [<ffffffff812dc41e>] __driver_attach+0x6e/0x90 | [<ffffffff812da234>] bus_for_each_dev+0x54/0x90 | [<ffffffff812dbbf9>] driver_attach+0x19/0x20 | [<ffffffff812db6a6>] bus_add_driver+0xe6/0x200 | [<ffffffff812dcb23>] driver_register+0x83/0xc0 | [<ffffffff816f050a>] acpi_processor_driver_init+0x20/0x94 | [<ffffffff81000487>] do_one_initcall+0x97/0x180 | [<ffffffff816ccf5c>] kernel_init_freeable+0x112/0x1a6 | [<ffffffff813a0fc9>] kernel_init+0x9/0xf0 | [<ffffffff813acf35>] ret_from_fork+0x25/0x30 |Code: 02 00 00 00 48 8b 14 d5 e0 c3 55 81 48 8b 1c 02 4c 8d 6b 20 eb 15 49 8b 7d 00 48 85 ff 74 05 e8 39 8c d9 ff 41 ff c4 49 83 c5 20 <44> 3b 23 72 e6 48 8d bb a0 02 00 00 e8 b1 6f f9 ff 48 89 df e8 |RIP [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 | RSP <ffffc9000000bd48> |CR2: 0000000000000000
Fix that and while at it, fix a possible use-after-free scenario in acpi_cppc_processor_probe() that can happen if the function returns without cleaning up the per-CPU pointer set by it previously.
---
Hi Thomas,
The crash fixed by this is exposed by the ITMT (asymmetric packing) series (which involves using ACPI CPPC on x86), so IMO it would be good to route it through tip along with that series.
Thanks,
Rafael
--- drivers/acpi/cppc_acpi.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/acpi/cppc_acpi.c +8 -4
@@ -776,9 +776,6 @@ int acpi_cppc_processor_probe(struct acpinit_waitqueue_head (&pcc_data.pcc_write_wait_q); } -/* Plug PSD data into this CPUs CPC descriptor. */ -per_cpu (cpc_desc_ptr, pr->id) = cpc_ptr; -/* Everything looks okay */ pr_debug ("Parsed CPC struct for CPU: %d\n" , pr->id);
@@ -789,10 +786,15 @@ int acpi_cppc_processor_probe(struct acp goto out_free; } +/* Plug PSD data into this CPUs CPC descriptor. */ +per_cpu (cpc_desc_ptr, pr->id) = cpc_ptr; + ret =kobject_init_and_add (&cpc_ptr->kobj, &cppc_ktype, &cpu_dev->kobj,"acpi_cppc" ); -if (ret) +if (ret) { +per_cpu (cpc_desc_ptr, pr->id) =NULL ; goto out_free; + }kfree (output.pointer);return 0 ;
@@ -826,6 +828,8 @@ void acpi_cppc_processor_exit(struct acpvoid __iomem *addr; cpc_ptr =per_cpu (cpc_desc_ptr, pr->id); +if (!cpc_ptr) +return ;/* Free all the mapped sys mem areas for this CPU */ for (i =2 ; i < cpc_ptr->num_entries; i++) {
Re: [PATCH] ACPI / CPPC: Fix per-CPU pointers management
Quoted 5 lines · Rafael J. Wysocki
Hi Thomas,
The crash fixed by this is exposed by the ITMT (asymmetric packing) series (which involves using ACPI CPPC on x86), so IMO it would be good to route it through tip along with that series.
can we get this merged into the original patch please? This is default y and breaks bisecting.
Quoted 2 lines
Thanks,
Rafael
Sebastian
Rafael J. Wysocki
maintainerRe: [PATCH] ACPI / CPPC: Fix per-CPU pointers management
Quoted 8 lines · Sebastian Andrzej Siewior
Quoted 5 lines · Rafael J. Wysocki
Hi Thomas,
The crash fixed by this is exposed by the ITMT (asymmetric packing) series (which involves using ACPI CPPC on x86), so IMO it would be good to route it through tip along with that series.
can we get this merged into the original patch please?
Functionally, that patch has a little to do with the fix, so I'd rather not do that.
Quoted 1 line
This is default y and breaks bisecting.
Instead, I would reorder the series to put the fix in front of that patch.
Thanks,
Rafael
Re: [PATCH] ACPI / CPPC: Fix per-CPU pointers management
In reply to Rafael J. WysockiQuoted 52 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Enabling ACPI CPPC on x86 causes a NULL pointer dereference to occur (on boot on a "default" KVM setup) in
acpi_cppc_processor_exit()due to a missing check against NULL in there:|BUG: unable to handle kernel NULL pointer dereference at (null) |IP: [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 |PGD 0 [ 0.577616] |Oops: 0000 [#1] SMP |Modules linked in: |CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc6-00146-g17669006adf6 #51 |task: ffff88003f878000 task.stack: ffffc90000008000 |RIP: 0010:[<ffffffff812aab6e>] [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 |RSP: 0000:ffffc9000000bd48 EFLAGS: 00010296 |RAX: 00000000000137e0 RBX: 0000000000000000 RCX: 0000000000000001 |RDX: ffff88003fc00000 RSI: 0000000000000000 RDI: ffff88003fbca130 |RBP: ffffc9000000bd60 R08: 0000000000000514 R09: 0000000000000000 |R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002 |R13: 0000000000000020 R14: ffffffff8167cb00 R15: 0000000000000000 |FS: 0000000000000000(0000) GS:ffff88003fcc0000(0000) knlGS:0000000000000000 |CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 |CR2: 0000000000000000 CR3: 0000000001618000 CR4: 00000000000406e0 |Stack: | ffff88003f939848 ffff88003fbca130 0000000000000001 ffffc9000000bd80 | ffffffff812a4ccb ffff88003fc0cee8 0000000000000000 ffffc9000000bdb8 | ffffffff812dc20d ffff88003fc0cee8 ffffffff8167cb00 ffff88003fc0cf48 |Call Trace: | [<ffffffff812a4ccb>] acpi_processor_stop+0xb2/0xc5 | [<ffffffff812dc20d>] driver_probe_device+0x14d/0x2f0 | [<ffffffff812dc41e>] __driver_attach+0x6e/0x90 | [<ffffffff812da234>] bus_for_each_dev+0x54/0x90 | [<ffffffff812dbbf9>] driver_attach+0x19/0x20 | [<ffffffff812db6a6>] bus_add_driver+0xe6/0x200 | [<ffffffff812dcb23>] driver_register+0x83/0xc0 | [<ffffffff816f050a>] acpi_processor_driver_init+0x20/0x94 | [<ffffffff81000487>] do_one_initcall+0x97/0x180 | [<ffffffff816ccf5c>] kernel_init_freeable+0x112/0x1a6 | [<ffffffff813a0fc9>] kernel_init+0x9/0xf0 | [<ffffffff813acf35>] ret_from_fork+0x25/0x30 |Code: 02 00 00 00 48 8b 14 d5 e0 c3 55 81 48 8b 1c 02 4c 8d 6b 20 eb 15 49 8b 7d 00 48 85 ff 74 05 e8 39 8c d9 ff 41 ff c4 49 83 c5 20 <44> 3b 23 72 e6 48 8d bb a0 02 00 00 e8 b1 6f f9 ff 48 89 df e8 |RIP [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60 | RSP <ffffc9000000bd48> |CR2: 0000000000000000Fix that and while at it, fix a possible use-after-free scenario in
acpi_cppc_processor_probe()that can happen if the function returns without cleaning up the per-CPU pointer set by it previously.Reported-by Sebastian Andrzej Siewior <[email protected]>Original-by Sebastian Andrzej Siewior <[email protected]>Signed-off-by Rafael J. Wysocki <[email protected]>
Quoted 7 lines
---
Hi Thomas,
The crash fixed by this is exposed by the ITMT (asymmetric packing) series (which involves using ACPI CPPC on x86), so IMO it would be good to route it through tip along with that series.
The problematic commit has gone in already, so I'll route the fix through the ACPI tree.
Thanks,
Rafael