| Message ID | 5ffc7b9ed03c6301ac2f710f609282959491b526.1608010334.git.viresh.kumar@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [V3,1/3] arm64: topology: Avoid the have_policy check | expand |
On 15-12-20, 11:04, Viresh Kumar wrote: > Every time I have stumbled upon this routine, I get confused with the > way 'have_policy' is used and I have to dig in to understand why is it > so. Here is an attempt to make it easier to understand, and hopefully it > is an improvement. > > The 'have_policy' check was just an optimization to avoid writing > to amu_fie_cpus in case we don't have to, but that optimization itself > is creating more confusion than the real work. Lets just do that if all > the CPUs support AMUs. It is much cleaner that way. > > Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > --- > V3: > - Added Reviewed by tag. Catalin, please pick the first two patches for 5.11. I will send the last one separately later on.
Hi Viresh, On Thu, Dec 17, 2020 at 01:27:32PM +0530, Viresh Kumar wrote: > On 15-12-20, 11:04, Viresh Kumar wrote: > > Every time I have stumbled upon this routine, I get confused with the > > way 'have_policy' is used and I have to dig in to understand why is it > > so. Here is an attempt to make it easier to understand, and hopefully it > > is an improvement. > > > > The 'have_policy' check was just an optimization to avoid writing > > to amu_fie_cpus in case we don't have to, but that optimization itself > > is creating more confusion than the real work. Lets just do that if all > > the CPUs support AMUs. It is much cleaner that way. > > > > Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > --- > > V3: > > - Added Reviewed by tag. > > Catalin, please pick the first two patches for 5.11. I will send the > last one separately later on. I haven't figured out whether these are fixes (a cover letter would help ;)). They look like generic improvements to me and given that we are already in the 5.11 merging window, they would probably need to wait until 5.12.
On 17-12-20, 10:55, Catalin Marinas wrote: > Hi Viresh, > > On Thu, Dec 17, 2020 at 01:27:32PM +0530, Viresh Kumar wrote: > > On 15-12-20, 11:04, Viresh Kumar wrote: > > > Every time I have stumbled upon this routine, I get confused with the > > > way 'have_policy' is used and I have to dig in to understand why is it > > > so. Here is an attempt to make it easier to understand, and hopefully it > > > is an improvement. > > > > > > The 'have_policy' check was just an optimization to avoid writing > > > to amu_fie_cpus in case we don't have to, but that optimization itself > > > is creating more confusion than the real work. Lets just do that if all > > > the CPUs support AMUs. It is much cleaner that way. > > > > > > Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > > --- > > > V3: > > > - Added Reviewed by tag. > > > > Catalin, please pick the first two patches for 5.11. I will send the > > last one separately later on. > > I haven't figured out whether these are fixes (a cover letter would > help ;)). They look like generic improvements to me Right they are and since the merge window just opened I thought these don't really need to wait for another full cycle to get in. > and given that we > are already in the 5.11 merging window, they would probably need to wait > until 5.12. Whatever you decide :)
On Fri, Dec 18, 2020 at 09:56:02AM +0530, Viresh Kumar wrote: > On 17-12-20, 10:55, Catalin Marinas wrote: > > Hi Viresh, > > > > On Thu, Dec 17, 2020 at 01:27:32PM +0530, Viresh Kumar wrote: > > > On 15-12-20, 11:04, Viresh Kumar wrote: > > > > Every time I have stumbled upon this routine, I get confused with the > > > > way 'have_policy' is used and I have to dig in to understand why is it > > > > so. Here is an attempt to make it easier to understand, and hopefully it > > > > is an improvement. > > > > > > > > The 'have_policy' check was just an optimization to avoid writing > > > > to amu_fie_cpus in case we don't have to, but that optimization itself > > > > is creating more confusion than the real work. Lets just do that if all > > > > the CPUs support AMUs. It is much cleaner that way. > > > > > > > > Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> > > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > > > --- > > > > V3: > > > > - Added Reviewed by tag. > > > > > > Catalin, please pick the first two patches for 5.11. I will send the > > > last one separately later on. > > > > I haven't figured out whether these are fixes (a cover letter would > > help ;)). They look like generic improvements to me > > Right they are and since the merge window just opened I thought these > don't really need to wait for another full cycle to get in. Normally we freeze the arm64 tree around the -rc6 prior to the merging window to give the patches a bit of time in linux-next. This time around, given the holidays, Linus even stated that if not already in -next at 5.10, it won't be pulled: https://lkml.org/lkml/2020/12/13/290. So please re-post at -rc1 with the acks in place.
On 18-12-20, 11:01, Catalin Marinas wrote: > On Fri, Dec 18, 2020 at 09:56:02AM +0530, Viresh Kumar wrote: > > On 17-12-20, 10:55, Catalin Marinas wrote: > > > Hi Viresh, > > > > > > On Thu, Dec 17, 2020 at 01:27:32PM +0530, Viresh Kumar wrote: > > > > On 15-12-20, 11:04, Viresh Kumar wrote: > > > > > Every time I have stumbled upon this routine, I get confused with the > > > > > way 'have_policy' is used and I have to dig in to understand why is it > > > > > so. Here is an attempt to make it easier to understand, and hopefully it > > > > > is an improvement. > > > > > > > > > > The 'have_policy' check was just an optimization to avoid writing > > > > > to amu_fie_cpus in case we don't have to, but that optimization itself > > > > > is creating more confusion than the real work. Lets just do that if all > > > > > the CPUs support AMUs. It is much cleaner that way. > > > > > > > > > > Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> > > > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > > > > --- > > > > > V3: > > > > > - Added Reviewed by tag. > > > > > > > > Catalin, please pick the first two patches for 5.11. I will send the > > > > last one separately later on. > > > > > > I haven't figured out whether these are fixes (a cover letter would > > > help ;)). They look like generic improvements to me > > > > Right they are and since the merge window just opened I thought these > > don't really need to wait for another full cycle to get in. > > Normally we freeze the arm64 tree around the -rc6 prior to the merging > window to give the patches a bit of time in linux-next. This time > around, given the holidays, Linus even stated that if not already in > -next at 5.10, it won't be pulled: https://lkml.org/lkml/2020/12/13/290. Okay, sounds good. > So please re-post at -rc1 with the acks in place. Sure.
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c index f6faa697e83e..ebadc73449f9 100644 --- a/arch/arm64/kernel/topology.c +++ b/arch/arm64/kernel/topology.c @@ -199,14 +199,14 @@ static int freq_inv_set_max_ratio(int cpu, u64 max_rate, u64 ref_rate) return 0; } -static inline bool +static inline void enable_policy_freq_counters(int cpu, cpumask_var_t valid_cpus) { struct cpufreq_policy *policy = cpufreq_cpu_get(cpu); if (!policy) { pr_debug("CPU%d: No cpufreq policy found.\n", cpu); - return false; + return; } if (cpumask_subset(policy->related_cpus, valid_cpus)) @@ -214,8 +214,6 @@ enable_policy_freq_counters(int cpu, cpumask_var_t valid_cpus) amu_fie_cpus); cpufreq_cpu_put(policy); - - return true; } static DEFINE_STATIC_KEY_FALSE(amu_fie_key); @@ -225,7 +223,6 @@ static int __init init_amu_fie(void) { bool invariance_status = topology_scale_freq_invariant(); cpumask_var_t valid_cpus; - bool have_policy = false; int ret = 0; int cpu; @@ -245,17 +242,12 @@ static int __init init_amu_fie(void) continue; cpumask_set_cpu(cpu, valid_cpus); - have_policy |= enable_policy_freq_counters(cpu, valid_cpus); + enable_policy_freq_counters(cpu, valid_cpus); } - /* - * If we are not restricted by cpufreq policies, we only enable - * the use of the AMU feature for FIE if all CPUs support AMU. - * Otherwise, enable_policy_freq_counters has already enabled - * policy cpus. - */ - if (!have_policy && cpumask_equal(valid_cpus, cpu_present_mask)) - cpumask_or(amu_fie_cpus, amu_fie_cpus, valid_cpus); + /* Overwrite amu_fie_cpus if all CPUs support AMU */ + if (cpumask_equal(valid_cpus, cpu_present_mask)) + cpumask_copy(amu_fie_cpus, cpu_present_mask); if (!cpumask_empty(amu_fie_cpus)) { pr_info("CPUs[%*pbl]: counters will be used for FIE.",