On 19-02-21, 09:44, Ionela Voinescu wrote:
> On Friday 19 Feb 2021 at 10:28:23 (+0530), Viresh Kumar wrote:
> > The very core routines (cpufreq_freq_transition_end() and
> > cpufreq_driver_fast_switch()) of the cpufreq core call
> > arch_set_freq_scale() today and this isn't going to change
On Friday 19 Feb 2021 at 10:28:23 (+0530), Viresh Kumar wrote:
> On 18-02-21, 16:36, Ionela Voinescu wrote:
> > Yes, we don't care if there is no cpufreq driver, as the use of AMUs won't
> > get initialised either. But we do care if there is a cpufreq driver that
> > does not support frequency
On 18-02-21, 16:36, Ionela Voinescu wrote:
> Yes, we don't care if there is no cpufreq driver, as the use of AMUs won't
> get initialised either. But we do care if there is a cpufreq driver that
> does not support frequency invariance, which is the example above.
>
> The intention with the
Hey,
On Thursday 18 Feb 2021 at 15:03:04 (+0530), Viresh Kumar wrote:
> On 17-02-21, 00:24, Ionela Voinescu wrote:
> > > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > > index 1e47dfd465f8..47fca7376c93 100644
> > > --- a/arch/arm64/kernel/topology.c
> > > +++
On 17-02-21, 00:24, Ionela Voinescu wrote:
> > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > index 1e47dfd465f8..47fca7376c93 100644
> > --- a/arch/arm64/kernel/topology.c
> > +++ b/arch/arm64/kernel/topology.c
> > @@ -240,7 +240,6 @@ static struct scale_freq_data
On 17-02-21, 11:57, Ionela Voinescu wrote:
> See a very useful comment someone added recently :) :
>
> """
> + /*
> + * We don't need to handle CPUFREQ_REMOVE_POLICY event as the AMU
> + * counters don't have any dependency on cpufreq driver once we have
> + * initialized AMU
On Wednesday 17 Feb 2021 at 17:10:27 (+0530), Viresh Kumar wrote:
> On 17-02-21, 11:30, Ionela Voinescu wrote:
> > The problem is not topology_scale_freq_invariant() but whether a scale
> > factor is set for some CPUs.
> >
> > Scenario (test system above):
> > - "AMUs" are only supported for
On 17-02-21, 11:30, Ionela Voinescu wrote:
> The problem is not topology_scale_freq_invariant() but whether a scale
> factor is set for some CPUs.
>
> Scenario (test system above):
> - "AMUs" are only supported for [1-2],
> - cpufreq_supports_freq_invariance() -> false
>
> What should happen:
Hi,
Replying this first as it's going to be relevant below:
> Just out of curiosity, what exactly did you test and what was the setup ? :)
I tested it on:
- Juno R0 (CPUs [0, 3-5] are littles, CPUs [1-2] are bigs)
+ PMUs faking AMUs
+ userspace/schedutil +
+ cpufreq-FIE/!cpufreq-FIE
On 17-02-21, 00:24, Ionela Voinescu wrote:
> I think it could be merged in patch 1/2 as it's part of enabling the use
> of multiple sources of information for FIE. Up to you!
Sure.
> > static void amu_fie_setup(const struct cpumask *cpus)
> > {
> > - bool invariant;
> > int cpu;
> >
>
Hey,
On Friday 05 Feb 2021 at 14:44:24 (+0530), Viresh Kumar wrote:
> On 03-02-21, 11:45, Ionela Voinescu wrote:
> > Therefore, I think system level invariance management (checks and
> > call to rebuild_sched_domains_energy()) also needs to move from arm64
> > code to arch_topology code.
>
>
On 03-02-21, 11:45, Ionela Voinescu wrote:
> Therefore, I think system level invariance management (checks and
> call to rebuild_sched_domains_energy()) also needs to move from arm64
> code to arch_topology code.
Here is the 3rd patch of this series then :)
From: Viresh Kumar
Date: Fri, 5 Feb
Hi Viresh,
Many thanks for the renaming of functions/variables/enums.
I've cropped all the code that looks good to me, and I kept some
portions of interest.
On Thursday 28 Jan 2021 at 16:18:55 (+0530), Viresh Kumar wrote:
> This patch attempts to make it generic enough so other parts of the
>
This patch attempts to make it generic enough so other parts of the
kernel can also provide their own implementation of scale_freq_tick()
callback, which is called by the scheduler periodically to update the
per-cpu freq_scale variable.
The implementations now need to provide struct
14 matches
Mail list logo
