From: Sudeep Holla <sudeep.holla@arm.com> To: Ionela Voinescu <ionela.voinescu@arm.com> Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, maz@kernel.org, suzuki.poulose@arm.com, lukasz.luba@arm.com, valentin.schneider@arm.com, dietmar.eggemann@arm.com, rjw@rjwysocki.net, pkondeti@codeaurora.org, peterz@infradead.org, mingo@redhat.com, vincent.guittot@linaro.org, viresh.kumar@linaro.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH v6 6/7] arm64: use activity monitors for frequency invariance Date: Fri, 6 Mar 2020 11:53:41 +0000 [thread overview] Message-ID: <20200306115341.GA44221@bogus> (raw) In-Reply-To: <20200305090627.31908-7-ionela.voinescu@arm.com> On Thu, Mar 05, 2020 at 09:06:26AM +0000, Ionela Voinescu wrote: > The Frequency Invariance Engine (FIE) is providing a frequency > scaling correction factor that helps achieve more accurate > load-tracking. > > So far, for arm and arm64 platforms, this scale factor has been > obtained based on the ratio between the current frequency and the > maximum supported frequency recorded by the cpufreq policy. The > setting of this scale factor is triggered from cpufreq drivers by > calling arch_set_freq_scale. The current frequency used in computation > is the frequency requested by a governor, but it may not be the > frequency that was implemented by the platform. > > This correction factor can also be obtained using a core counter and a > constant counter to get information on the performance (frequency based > only) obtained in a period of time. This will more accurately reflect > the actual current frequency of the CPU, compared with the alternative > implementation that reflects the request of a performance level from > the OS. > > Therefore, implement arch_scale_freq_tick to use activity monitors, if > present, for the computation of the frequency scale factor. > > The use of AMU counters depends on: > - CONFIG_ARM64_AMU_EXTN - depents on the AMU extension being present > - CONFIG_CPU_FREQ - the current frequency obtained using counter > information is divided by the maximum frequency obtained from the > cpufreq policy. > > While it is possible to have a combination of CPUs in the system with > and without support for activity monitors, the use of counters for > frequency invariance is only enabled for a CPU if all related CPUs > (CPUs in the same frequency domain) support and have enabled the core > and constant activity monitor counters. In this way, there is a clear > separation between the policies for which arch_set_freq_scale (cpufreq > based FIE) is used, and the policies for which arch_scale_freq_tick > (counter based FIE) is used to set the frequency scale factor. For > this purpose, a late_initcall_sync is registered to trigger validation > work for policies that will enable or disable the use of AMU counters > for frequency invariance. If CONFIG_CPU_FREQ is not defined, the use > of counters is enabled on all CPUs only if all possible CPUs correctly > support the necessary counters. > > Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> > Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Will Deacon <will@kernel.org> > Cc: Sudeep Holla <sudeep.holla@arm.com> > --- > arch/arm64/include/asm/topology.h | 9 ++ > arch/arm64/kernel/cpufeature.c | 4 + > arch/arm64/kernel/topology.c | 180 ++++++++++++++++++++++++++++++ > drivers/base/arch_topology.c | 12 ++ > include/linux/arch_topology.h | 2 + > 5 files changed, 207 insertions(+) > [...] > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index 6119e11a9f95..8d63673c1689 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -21,6 +21,10 @@ > #include <linux/sched.h> > #include <linux/smp.h> > > +__weak bool arch_freq_counters_available(struct cpumask *cpus) > +{ > + return false; > +} > DEFINE_PER_CPU(unsigned long, freq_scale) = SCHED_CAPACITY_SCALE; > > void arch_set_freq_scale(struct cpumask *cpus, unsigned long cur_freq, > @@ -29,6 +33,14 @@ void arch_set_freq_scale(struct cpumask *cpus, unsigned long cur_freq, > unsigned long scale; > int i; > > + /* > + * If the use of counters for FIE is enabled, just return as we don't > + * want to update the scale factor with information from CPUFREQ. > + * Instead the scale factor will be updated from arch_scale_freq_tick. > + */ > + if (arch_freq_counters_available(cpus)) > + return; > + > scale = (cur_freq << SCHED_CAPACITY_SHIFT) / max_freq; > > for_each_cpu(i, cpus) > diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h > index 3015ecbb90b1..1ccdddb541a7 100644 > --- a/include/linux/arch_topology.h > +++ b/include/linux/arch_topology.h > @@ -33,6 +33,8 @@ unsigned long topology_get_freq_scale(int cpu) > return per_cpu(freq_scale, cpu); > } > > +bool arch_freq_counters_available(struct cpumask *cpus); > + > struct cpu_topology { > int thread_id; > int core_id; Sorry for the delay. The arch_topology part looks fine to me. For that part: Acked-by: Sudeep Holla <sudeep.holla@arm.com> -- Regards, Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com> To: Ionela Voinescu <ionela.voinescu@arm.com> Cc: mark.rutland@arm.com, suzuki.poulose@arm.com, pkondeti@codeaurora.org, catalin.marinas@arm.com, linux-pm@vger.kernel.org, linux-doc@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com, peterz@infradead.org, mingo@redhat.com, viresh.kumar@linaro.org, linux-arm-kernel@lists.infradead.org, maz@kernel.org, will@kernel.org, valentin.schneider@arm.com, lukasz.luba@arm.com Subject: Re: [PATCH v6 6/7] arm64: use activity monitors for frequency invariance Date: Fri, 6 Mar 2020 11:53:41 +0000 [thread overview] Message-ID: <20200306115341.GA44221@bogus> (raw) In-Reply-To: <20200305090627.31908-7-ionela.voinescu@arm.com> On Thu, Mar 05, 2020 at 09:06:26AM +0000, Ionela Voinescu wrote: > The Frequency Invariance Engine (FIE) is providing a frequency > scaling correction factor that helps achieve more accurate > load-tracking. > > So far, for arm and arm64 platforms, this scale factor has been > obtained based on the ratio between the current frequency and the > maximum supported frequency recorded by the cpufreq policy. The > setting of this scale factor is triggered from cpufreq drivers by > calling arch_set_freq_scale. The current frequency used in computation > is the frequency requested by a governor, but it may not be the > frequency that was implemented by the platform. > > This correction factor can also be obtained using a core counter and a > constant counter to get information on the performance (frequency based > only) obtained in a period of time. This will more accurately reflect > the actual current frequency of the CPU, compared with the alternative > implementation that reflects the request of a performance level from > the OS. > > Therefore, implement arch_scale_freq_tick to use activity monitors, if > present, for the computation of the frequency scale factor. > > The use of AMU counters depends on: > - CONFIG_ARM64_AMU_EXTN - depents on the AMU extension being present > - CONFIG_CPU_FREQ - the current frequency obtained using counter > information is divided by the maximum frequency obtained from the > cpufreq policy. > > While it is possible to have a combination of CPUs in the system with > and without support for activity monitors, the use of counters for > frequency invariance is only enabled for a CPU if all related CPUs > (CPUs in the same frequency domain) support and have enabled the core > and constant activity monitor counters. In this way, there is a clear > separation between the policies for which arch_set_freq_scale (cpufreq > based FIE) is used, and the policies for which arch_scale_freq_tick > (counter based FIE) is used to set the frequency scale factor. For > this purpose, a late_initcall_sync is registered to trigger validation > work for policies that will enable or disable the use of AMU counters > for frequency invariance. If CONFIG_CPU_FREQ is not defined, the use > of counters is enabled on all CPUs only if all possible CPUs correctly > support the necessary counters. > > Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> > Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Will Deacon <will@kernel.org> > Cc: Sudeep Holla <sudeep.holla@arm.com> > --- > arch/arm64/include/asm/topology.h | 9 ++ > arch/arm64/kernel/cpufeature.c | 4 + > arch/arm64/kernel/topology.c | 180 ++++++++++++++++++++++++++++++ > drivers/base/arch_topology.c | 12 ++ > include/linux/arch_topology.h | 2 + > 5 files changed, 207 insertions(+) > [...] > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index 6119e11a9f95..8d63673c1689 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -21,6 +21,10 @@ > #include <linux/sched.h> > #include <linux/smp.h> > > +__weak bool arch_freq_counters_available(struct cpumask *cpus) > +{ > + return false; > +} > DEFINE_PER_CPU(unsigned long, freq_scale) = SCHED_CAPACITY_SCALE; > > void arch_set_freq_scale(struct cpumask *cpus, unsigned long cur_freq, > @@ -29,6 +33,14 @@ void arch_set_freq_scale(struct cpumask *cpus, unsigned long cur_freq, > unsigned long scale; > int i; > > + /* > + * If the use of counters for FIE is enabled, just return as we don't > + * want to update the scale factor with information from CPUFREQ. > + * Instead the scale factor will be updated from arch_scale_freq_tick. > + */ > + if (arch_freq_counters_available(cpus)) > + return; > + > scale = (cur_freq << SCHED_CAPACITY_SHIFT) / max_freq; > > for_each_cpu(i, cpus) > diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h > index 3015ecbb90b1..1ccdddb541a7 100644 > --- a/include/linux/arch_topology.h > +++ b/include/linux/arch_topology.h > @@ -33,6 +33,8 @@ unsigned long topology_get_freq_scale(int cpu) > return per_cpu(freq_scale, cpu); > } > > +bool arch_freq_counters_available(struct cpumask *cpus); > + > struct cpu_topology { > int thread_id; > int core_id; Sorry for the delay. The arch_topology part looks fine to me. For that part: Acked-by: Sudeep Holla <sudeep.holla@arm.com> -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-06 11:53 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-05 9:06 [PATCH v6 0/7] arm64: ARMv8.4 Activity Monitors support Ionela Voinescu 2020-03-05 9:06 ` Ionela Voinescu 2020-03-05 9:06 ` [PATCH v6 1/7] arm64: add support for the AMU extension v1 Ionela Voinescu 2020-03-05 9:06 ` Ionela Voinescu 2020-03-05 9:06 ` [PATCH v6 2/7] arm64: trap to EL1 accesses to AMU counters from EL0 Ionela Voinescu 2020-03-05 9:06 ` Ionela Voinescu 2020-03-05 9:06 ` [PATCH v6 3/7] arm64/kvm: disable access to AMU registers from kvm guests Ionela Voinescu 2020-03-05 9:06 ` Ionela Voinescu 2020-03-05 9:06 ` [PATCH v6 4/7] Documentation: arm64: document support for the AMU extension Ionela Voinescu 2020-03-05 9:06 ` Ionela Voinescu 2020-03-05 9:06 ` [PATCH v6 5/7] cpufreq: add function to get the hardware max frequency Ionela Voinescu 2020-03-05 9:06 ` Ionela Voinescu 2020-03-05 9:06 ` [PATCH v6 6/7] arm64: use activity monitors for frequency invariance Ionela Voinescu 2020-03-05 9:06 ` Ionela Voinescu 2020-03-06 11:53 ` Sudeep Holla [this message] 2020-03-06 11:53 ` Sudeep Holla 2020-03-05 9:06 ` [PATCH v6 7/7] clocksource/drivers/arm_arch_timer: validate arch_timer_rate Ionela Voinescu 2020-03-05 9:06 ` Ionela Voinescu 2020-03-06 11:21 ` [PATCH v6 0/7] arm64: ARMv8.4 Activity Monitors support Catalin Marinas 2020-03-06 11:21 ` Catalin Marinas 2020-03-09 14:11 ` Ionela Voinescu 2020-03-09 14:11 ` Ionela Voinescu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200306115341.GA44221@bogus \ --to=sudeep.holla@arm.com \ --cc=catalin.marinas@arm.com \ --cc=dietmar.eggemann@arm.com \ --cc=ionela.voinescu@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=lukasz.luba@arm.com \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=pkondeti@codeaurora.org \ --cc=rjw@rjwysocki.net \ --cc=suzuki.poulose@arm.com \ --cc=valentin.schneider@arm.com \ --cc=vincent.guittot@linaro.org \ --cc=viresh.kumar@linaro.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.