Support Intel® Turbo Boost Max Technology 3.0
Subsystems (5)
v6 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.
Refer to:
http://www.intel.com/content/www/us/en/architecture-and-technology/turbo-boost/turbo-boost-max-technology.html
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:
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 (6):
sched: Extend scheduler's asym packing x86/topology: Provide topology_num_packages() 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 | 35 +++++++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/itmt.c | 217 ++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/smpboot.c | 44 +++++++- 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 | 2 + kernel/sched/core.c | 15 +++ kernel/sched/fair.c | 35 +++++-- kernel/sched/sched.h | 6 ++ 13 files changed, 416 insertions(+), 16 deletions(-) create mode 100644 arch/x86/kernel/itmt.c
Signature · 36 lines
2.5.5 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 (6): sched: Extend scheduler's asym packing x86/topology: Provide topology_num_packages() 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 | 35 +++++++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/itmt.c | 217 ++++++++++++++++++++++++++++++++++++++++ arch/x86/kernel/smpboot.c | 44 +++++++- 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 | 2 + kernel/sched/core.c | 15 +++ kernel/sched/fair.c | 35 +++++-- kernel/sched/sched.h | 6 ++ 13 files changed, 416 insertions(+), 16 deletions(-) create mode 100644 arch/x86/kernel/itmt.c -- 2.5.5
PATCH v6 1/9 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 | 35 ++++++++++++++++++++++++----------- kernel/sched/sched.h | 6 ++++++ 4 files changed, 47 insertions(+), 11 deletions(-)
include/linux/sched.h +2 -0
@@ -1057,6 +1057,8 @@ static inline int cpu_numa_flags(void) }#endif +int arch_asym_cpu_priority (int cpu); +struct sched_domain_attr {int relax_domain_level; };
kernel/sched/core.c +15 -0
@@ -6307,7 +6307,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 +24 -11
@@ -100,6 +100,16 @@ const_debug unsigned int sysctl_sched_migration_cost = 500000UL;*/ unsigned int __read_mostly sysctl_sched_shares_window =10000000UL ; +#ifdef CONFIG_SMP +/* +* For asym packing, by default the lower numbered cpu has higher priority. +*/ +int __weak arch_asym_cpu_priority (int cpu) +{ +return -cpu; +} +#endif +#ifdef CONFIG_CFS_BANDWIDTH /* * Amount of runtime to allocate from global (tg) to local (per-cfs_rq) pool
@@ -7101,16 +7111,18 @@ static bool update_sd_pick_busiest(struct lb_env *env,if (env->idle ==CPU_NOT_IDLE )return true;/* -* ASYM_PACKING needs to move all the work to the lowest -* numbered CPUs in the group, therefore mark all groups -* higher than ourself as busy. +* ASYM_PACKING needs to move all the work to the highest +* prority CPUs in the group, therefore mark all groups +* of lower priority than ourself as busy. */ -if (sgs->sum_nr_running && env->dst_cpu <group_first_cpu (sg)) { +if (sgs->sum_nr_running && +sched_asym_prefer (env->dst_cpu, sg->asym_prefer_cpu)) {if (!sds->busiest)return true; -/* Prefer to move from highest possible cpu's work */ -if (group_first_cpu (sds->busiest) <group_first_cpu (sg)) +/* Prefer to move from lowest priority cpu's work */ +if (sched_asym_prefer (sds->busiest->asym_prefer_cpu, + sg->asym_prefer_cpu))return true; }
@@ -7262,8 +7274,8 @@ static int check_asym_packing(struct lb_env *env, struct sd_lb_stats *sds)if (!sds->busiest)return 0 ; - busiest_cpu =group_first_cpu (sds->busiest); -if (env->dst_cpu > busiest_cpu) + busiest_cpu = sds->busiest->asym_prefer_cpu; +if (sched_asym_prefer (busiest_cpu, env->dst_cpu))return 0 ; env->imbalance = DIV_ROUND_CLOSEST(
@@ -7601,10 +7613,11 @@ static int need_active_balance(struct lb_env *env)/* * ASYM_PACKING needs to force migrate tasks from busy but -* higher numbered CPUs in order to pack all tasks in the -* lowest numbered CPUs. +* lower priority CPUs in order to pack all tasks in the +* highest priority CPUs. */ -if ((sd->flags &SD_ASYM_PACKING ) && env->src_cpu > env->dst_cpu) +if ((sd->flags &SD_ASYM_PACKING ) && +sched_asym_prefer (env->dst_cpu, env->src_cpu))return 1 ; }
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 v6 1/9] 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 7 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.
Signed-off-by Tim Chen <[email protected]>Signed-off-by Peter Zijlstra (Intel) <[email protected]>Signed-off-by Srinivas Pandruvada <[email protected]>
This SOB-chain is bogus. Same for all other patches.
Thanks,
tglx
Re: [PATCH v6 1/9] sched: Extend scheduler's asym packing
Quoted 9 lines · Thomas Gleixner
Quoted 7 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 9 lines
Quoted 7 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.
Signed-off-by Tim Chen <[email protected]>Signed-off-by Peter Zijlstra (Intel) <[email protected]>Signed-off-by Srinivas Pandruvada <[email protected]>This SOB-chain is bogus. Same for all other patches.
I am the primary author of the patch so I have my sign-off on top. There were also much internal discussions/reviews between myself, Peter and Srinivas, before we post the first version of this patch.
I incorporated their inputs into the patch and added their sign-offs.
Can you be more explicit on why you think the sign-offs here are bogus?
Thanks.
Tim
Re: [PATCH v6 1/9] sched: Extend scheduler's asym packing
Quoted 20 lines · Tim Chen
Quoted 9 lines · Thomas Gleixner
Quoted 7 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 9 lines
Quoted 7 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.
Signed-off-by Tim Chen <[email protected]>Signed-off-by Peter Zijlstra (Intel) <[email protected]>Signed-off-by Srinivas Pandruvada <[email protected]>This SOB-chain is bogus. Same for all other patches.
Quoted 6 lines
I am the primary author of the patch so I have my sign-off on top. There were also much internal discussions/reviews between myself, Peter and Srinivas, before we post the first version of this patch.
I incorporated their inputs into the patch and added their sign-offs.Can you be more explicit on why you think the sign-offs here are bogus?
Because SOB chains document the way a patch takes from the author to the kernel. The above says:
You authored the patch and sent it to Peter who sent it to Srinivas. So how does it end up sent from you in my inbox?
We have no formal tag for co developed patches, but it's common practice to either acknowledge contributions from others in free text form or use a non-documented tag like 'Co-developed-by:' or 'Co-authored-by:'.
Thanks,
tglx
PATCH v6 2/9 x86/topology: Provide topology_num_packages()
In reply to Tim ChenReturns number of cpu packages discovered.
This information is needed to determine the size of the platform and decide if the Intel Turbo Boost Max Technology 3.0 (ITMT) feature should be turned on by default. The ITMT feature is more effective on single socket client like system that uses small number of cores most of the time.
--- arch/x86/include/asm/topology.h | 3 +++ arch/x86/kernel/smpboot.c | 5 +++++ 2 files changed, 8 insertions(+)
arch/x86/include/asm/topology.h +3 -0
@@ -129,10 +129,13 @@ static inline int topology_max_smt_threads(void) }int topology_update_package_map (unsigned int apicid,unsigned int cpu); +extern int topology_num_packages (void );extern int topology_phys_to_logical_pkg (unsigned int pkg);#else #define topology_max_packages () (1)static inline int +topology_num_packages (void ) {return 1 ; } +static inline int topology_update_package_map (unsigned int apicid,unsigned int cpu) {return 0 ; }static inline int topology_phys_to_logical_pkg (unsigned int pkg) {return 0 ; }static inline int topology_max_smt_threads (void ) {return 1 ; }
arch/x86/kernel/smpboot.c +5 -0
@@ -295,6 +295,11 @@ int topology_update_package_map(unsigned int apicid, unsigned int cpu)return 0 ; } +int topology_num_packages (void ) +{ +return logical_packages; +} +/** * topology_phys_to_logical_pkg - Map a physical package id to a logical *
Signature · 1 line
2.5.5
PATCH v6 3/9 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
@@ -149,4 +149,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
PATCH v6 4/9 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
@@ -150,4 +150,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
PATCH v6 5/9 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 | 110 +++++++++++++++++++++++++++++++++++++++- 2 files changed, 114 insertions(+), 3 deletions(-)
arch/x86/include/asm/topology.h +5 -2
@@ -155,23 +155,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 +109 -1
142 lines not on this page · raw message
Signature · 1 line
2.5.5
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
arch/x86/kernel/itmt.c DEFINE_PER_CPU_READ_MOSTLY(int, sched_core_priority); · line 47
Quoted 2 lines · Tim Chen
arch/x86/kernel/itmt.c +2
-0+static int sched_itmt_update_handler (struct ctl_table *table,int write, +void __user *buffer,size_t *lenp,loff_t *ppos)
Please align the arguments proper
static int
sched_itmt_update_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
arch/x86/kernel/itmt.c DEFINE_PER_CPU_READ_MOSTLY(int, sched_core_priority); · line 50
Quoted 3 lines
arch/x86/kernel/itmt.c +3
-0+{ +int ret; +unsigned int old_sysctl;
unsigned int old_sysctl; int ret;
Please. It's way simpler to read.
Quoted 14 lines
arch/x86/kernel/itmt.c +10
-1-void sched_set_itmt_support (void ) +int sched_set_itmt_support (void ) {mutex_lock (&itmt_update_mutex); +if (sched_itmt_capable) { +mutex_unlock (&itmt_update_mutex); +return 0 ; + } + + itmt_sysctl_header =register_sysctl_table (itmt_root_table); +if (!itmt_sysctl_header) { +mutex_unlock (&itmt_update_mutex); +return -ENOMEM ;
arch/x86/kernel/itmt.c static bool __read_mostly sched_itmt_capable; · line 137
Quoted 10 lines
arch/x86/kernel/itmt.c +8
-0+ } + sched_itmt_capable = true; +/* +* ITMT capability automatically enables ITMT +* scheduling for small systems (single node). +*/ +if (topology_num_packages () ==1 ) + sysctl_sched_itmt_enabled =1 ;
I really hate this. This is policy and the kernel should not impose policy. Why would I like to have this enforced on my single socket XEON server?
Review
Quoted 1 line
(quoted diff) +1
-0+ if (sysctl_sched_itmt_enabled) {
Why would sysctl_sched_itmt_enabled be true at this point, aside of the above policy imposement?
Thanks,
tglx
Peter Zijlstra
maintainerRe: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 10 lines · Thomas Gleixner
arch/x86/kernel/itmt.c static bool __read_mostly sched_itmt_capable; · line 137
Quoted 6 lines
arch/x86/kernel/itmt.c +6
-0+/* +* ITMT capability automatically enables ITMT +* scheduling for small systems (single node). +*/ +if (topology_num_packages () ==1 ) + sysctl_sched_itmt_enabled =1 ;I really hate this. This is policy and the kernel should not impose policy. Why would I like to have this enforced on my single socket XEON server?
So this really wants to be enabled by default; otherwise nobody will use this, and it really does help single threaded workloads.
There were reservations on the multi-socket case of ITMT, maybe it would help to spell those out in great detail here. That is, have the comment explain the policy instead of simply stating what the code does (which is always bad comment policy, you can read the code just fine).
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 13 lines · Peter Zijlstra
Quoted 10 lines · Thomas Gleixner
arch/x86/kernel/itmt.c static bool __read_mostly sched_itmt_capable; · line 137
Quoted 6 lines
arch/x86/kernel/itmt.c +6
-0+/* +* ITMT capability automatically enables ITMT +* scheduling for small systems (single node). +*/ +if (topology_num_packages () ==1 ) + sysctl_sched_itmt_enabled =1 ;I really hate this. This is policy and the kernel should not impose policy. Why would I like to have this enforced on my single socket XEON server?
Quoted 2 lines
So this really wants to be enabled by default; otherwise nobody will use this, and it really does help single threaded workloads.
Fair enough. Then this wants to be documented.
Quoted 4 lines
There were reservations on the multi-socket case of ITMT, maybe it would help to spell those out in great detail here. That is, have the comment explain the policy instead of simply stating what the code does (which is always bad comment policy, you can read the code just fine).
What is the objection for multi sockets? If it improves the behaviour then why would this be a bad thing for multi sockets?
Thanks,
tglx
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 20 lines · Thomas Gleixner
Quoted 14 lines · Peter Zijlstra
Quoted 11 lines · Thomas Gleixner
arch/x86/kernel/itmt.c static bool __read_mostly sched_itmt_capable; · line 137
Quoted 8 lines
arch/x86/kernel/itmt.c +6
-0+/* +* ITMT capability automatically enables ITMT +* scheduling for small systems (single node). +*/ +if (topology_num_packages () ==1 ) + sysctl_sched_itmt_enabled =1 ;I really hate this. This is policy and the kernel should not impose policy. Why would I like to have this enforced on my single socket XEON server?
Quoted 2 lines
So this really wants to be enabled by default; otherwise nobody will use this, and it really does help single threaded workloads.
Fair enough. Then this wants to be documented.
Quoted 1 line
Quoted 6 lines
Quoted 4 lines
There were reservations on the multi-socket case of ITMT, maybe it would help to spell those out in great detail here. That is, have the comment explain the policy instead of simply stating what the code does (which is always bad comment policy, you can read the code just fine).
What is the objection for multi sockets? If it improves the behaviour then why would this be a bad thing for multi sockets?
For multi-socket (server system), it is much more likely that they will have multiple cpus in a socket busy and not run in turbo mode. So the extra work in migrating the workload to the one with extra headroom will not make use of those headroom in that scenario. I will update the comment to reflect this policy.
See also our previous discussions: http://lkml.iu.edu/hypermail/linux/kernel/1609.1/03381.html
Tim
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 5 lines · Tim Chen
Quoted 4 lines · Thomas Gleixner
Quoted 4 lines
There were reservations on the multi-socket case of ITMT, maybe it would help to spell those out in great detail here. That is, have the comment explain the policy instead of simply stating what the code does (which is always bad comment policy, you can read the code just fine).
Quoted 8 lines
Quoted 2 lines
What is the objection for multi sockets? If it improves the behaviour then why would this be a bad thing for multi sockets?
For multi-socket (server system), it is much more likely that they will have multiple cpus in a socket busy and not run in turbo mode. So the extra work in migrating the workload to the one with extra headroom will not make use of those headroom in that scenario. I will update the comment to reflect this policy.
So on a single socket server system the extra work does not matter, right? Don't tell me that single socket server systems are irrelevant. Intel is actively promoting single socket CPUs, like XEON D, for high densitiy servers...
Instead of handwaving arguments I prefer a proper analysis of what the overhead is and why it is not a good thing for loaded servers in general.
Then instead of slapping half baken heuristics into the code, we should sit down and think a bit harder about it.
Thanks,
tglx
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 21 lines · Thomas Gleixner
Quoted 8 lines · Tim Chen
Quoted 6 lines · Thomas Gleixner
Quoted 6 lines
There were reservations on the multi-socket case of ITMT, maybe it would help to spell those out in great detail here. That is, have the comment explain the policy instead of simply stating what the code does (which is always bad comment policy, you can read the code just fine).
Quoted 7 lines
Quoted 2 lines
What is the objection for multi sockets? If it improves the behaviour then why would this be a bad thing for multi sockets?
For multi-socket (server system), it is much more likely that they will have multiple cpus in a socket busy and not run in turbo mode. So the extra work in migrating the workload to the one with extra headroom will not make use of those headroom in that scenario. I will update the comment to reflect this policy.
So on a single socket server system the extra work does not matter, right? Don't tell me that single socket server systems are irrelevant. Intel is actively promoting single socket CPUs, like XEON D, for high densitiy servers...
Quoted 6 lines
Instead of handwaving arguments I prefer a proper analysis of what the overhead is and why it is not a good thing for loaded servers in general.
Then instead of slapping half baken heuristics into the code, we should sit down and think a bit harder about it.
The ITMT scheduling overhead should be small. Mostly a small number of
cycles initially spent to idle balance tasks towards an idled favored core, and cycles to refill hot data in the mid level cache for the migrated task. Those should be a very small percentage of the cycles that the task spent running on the favored core. So any extra boost in frequency should compensate so should be a good trade off.
After some internal discussions, we think we should enable the ITMT feature by default for all systems supporting ITMT. I will remove the single socket restriction.
Thanks.
Tim
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
In reply to Thomas GleixnerQuoted 10 lines · Thomas Gleixner
arch/x86/kernel/itmt.c DEFINE_PER_CPU_READ_MOSTLY(int, sched_core_priority); · line 47
Quoted 3 lines · Tim Chen
arch/x86/kernel/itmt.c +2
-0+static int sched_itmt_update_handler (struct ctl_table *table,int write, + void __user *buffer, size_t *lenp, loff_t *ppos)Please align the arguments proper
static int
sched_itmt_update_handler(structctl_table*table, int write,
void__user*buffer,size_t*lenp,loff_t*ppos)
Okay.
Quoted 8 lines
arch/x86/kernel/itmt.c DEFINE_PER_CPU_READ_MOSTLY(int, sched_core_priority); · line 50
Quoted 4 lines
arch/x86/kernel/itmt.c +3
-0+{ +int ret; +unsigned int old_sysctl;unsigned int old_sysctl; int ret;Please. It's way simpler to read.
Sure.
Quoted 31 lines
Quoted 20 lines
arch/x86/kernel/itmt.c +1
-1-void sched_set_itmt_support (void ) +int sched_set_itmt_support (void ){
mutex_lock(&itmt_update_mutex);arch/x86/kernel/itmt.c +11
-0+if (sched_itmt_capable) { +mutex_unlock (&itmt_update_mutex); +return 0 ; + } + + itmt_sysctl_header =register_sysctl_table (itmt_root_table); +if (!itmt_sysctl_header) { +mutex_unlock (&itmt_update_mutex); +return -ENOMEM ; + } +
sched_itmt_capable= true;arch/x86/kernel/itmt.c static bool __read_mostly sched_itmt_capable; · line 137
Quoted 6 lines
arch/x86/kernel/itmt.c +6
-0+/* +* ITMT capability automatically enables ITMT +* scheduling for small systems (single node). +*/ +if (topology_num_packages () ==1 ) + sysctl_sched_itmt_enabled =1 ;I really hate this. This is policy and the kernel should not impose policy. Why would I like to have this enforced on my single socket XEON server?
Quoted 1 line
Quoted 3 lines
Review
Quoted 1 line
(quoted diff) +1
-0+ if (sysctl_sched_itmt_enabled) {Why would
sysctl_sched_itmt_enabledbe true at this point, aside of the above policy imposement?
That's true, it will only be enabled for the above case. I can merge it into the if check above.
Tim
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
In reply to Tim Chenarch/x86/kernel/itmt.c void sched_set_itmt_support(void) · line 170
Quoted 3 lines · Tim Chen
arch/x86/kernel/itmt.c +2
-0+if (itmt_sysctl_header) +unregister_sysctl_table (itmt_sysctl_header);
What sets itmt_sysctl_header to NULL?
Thanks,
tglx
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 7 lines · Thomas Gleixner
arch/x86/kernel/itmt.c void sched_set_itmt_support(void) · line 170
Quoted 4 lines · Tim Chen
arch/x86/kernel/itmt.c +2
-0+if (itmt_sysctl_header) +unregister_sysctl_table (itmt_sysctl_header);What sets
itmt_sysctl_headerto NULL?
If the registration of the itmt sysctl table has failed, it will be NULL.
Tim
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 11 lines · Tim Chen
Quoted 7 lines · Thomas Gleixner
arch/x86/kernel/itmt.c void sched_set_itmt_support(void) · line 170
Quoted 4 lines · Tim Chen
arch/x86/kernel/itmt.c +2
-0+if (itmt_sysctl_header) +unregister_sysctl_table (itmt_sysctl_header);What sets
itmt_sysctl_headerto NULL?If the registration of the itmt sysctl table has failed, it will be NULL.
And what clears it _AFTER_ the deregistration? Nothing, AFAICT.
Re: [PATCH v6 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
Quoted 8 lines · Thomas Gleixner
Quoted 6 lines · Tim Chen
Quoted 4 lines · Thomas Gleixner
Quoted 2 lines · Tim Chen
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
arch/x86/kernel/itmt.c void sched_set_itmt_support(void) · line 170
Quoted 3 lines
arch/x86/kernel/itmt.c +2
-0+if (itmt_sysctl_header) +unregister_sysctl_table (itmt_sysctl_header);What sets
itmt_sysctl_headerto NULL?If the registration of the itmt sysctl table has failed, it will be NULL.
And what clears it _AFTER_ the deregistration? Nothing, AFAICT.
Ok. I'll clear itmt_sysctl_header here.
Thanks.
Tim
PATCH v6 6/9 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
@@ -487,22 +487,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
PATCH v6 7/9 acpi: bus: Enable HWP CPPC objects
In reply to Tim ChenFrom: Srinivas Pandruvada <[email protected]>
From: 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
PATCH v6 8/9 acpi: bus: Set _OSC for diverse core support
In reply to Tim ChenFrom: Srinivas Pandruvada <[email protected]>
From: 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
@@ -468,6 +468,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
PATCH v6 9/9 cpufreq: intel_pstate: Use CPPC to get max performance
In reply to Tim ChenFrom: "Rafael J. Wysocki" <[email protected]>
From: 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