From: Ionela Voinescu <ionela.voinescu@arm.com> To: Viresh Kumar <viresh.kumar@linaro.org> Cc: Rafael Wysocki <rjw@rjwysocki.net>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Vincent Guittot <vincent.guittot@linaro.org>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, Sudeep Holla <sudeep.holla@arm.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Subject: Re: [PATCH V3 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback Date: Wed, 17 Feb 2021 11:30:11 +0000 [thread overview] Message-ID: <20210217113011.GA22176@arm.com> (raw) In-Reply-To: <20210217042558.o4anjdkayzgqny55@vireshk-i7> 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 + DT This testing did not yet cover patch 2/2. My checklist shows: - system invariance status correct - passed - scale factor correct (userspace cpufreq governor) - passed - arch_set_freq_scale bypassed - passed - partial "AMUs" support - failed (see below) - EAS enabling - passed I don't have an automated process for this as many test cases involve kernel source changes. In time I will automate all of these and possibly cover all scenarios with FVP (fast models) testing, but for now human error is possible :). On Wednesday 17 Feb 2021 at 09:55:58 (+0530), Viresh Kumar wrote: > 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; > > > > > > /* We are already set since the last insmod of cpufreq driver */ > > > @@ -257,25 +256,10 @@ static void amu_fie_setup(const struct cpumask *cpus) > > > > > > cpumask_or(amu_fie_cpus, amu_fie_cpus, cpus); > > > > > > - invariant = topology_scale_freq_invariant(); > > > - > > > - /* We aren't fully invariant yet */ > > > - if (!invariant && !cpumask_equal(amu_fie_cpus, cpu_present_mask)) > > > - return; > > > - > > > > You still need these checks, otherwise you could end up with only part > > of the CPUs setting a scale factor, when only part of the CPUs support > > AMUs and there is no cpufreq support for FIE. > > Both supports_scale_freq_counters() and topology_scale_freq_invariant() take > care of this now and they will keep reporting the system as invariant until the > time all the CPUs have counters (in absence of cpufreq). > Correct! > The topology_set_scale_freq_source() API is supposed to be called multiple > times, probably once for each policy and so I don't see a need of these checks > anymore. > 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: - topology_scale_freq_invariant() -> false (passed) - all CPUs should have their freq_scale unmodified (1024) - (failed) because only 2 out of 6 CPUs have a method of setting a scale factor What does happen: - arch_set_freq_tick() -> topology_set_freq_tick() will set a scale factor for [1-2] based on AMUs. This should not happen. We will end up with invariant signals for bigs and signals that are not freq invariant for littles. Ionela. > > Small(ish) optimisation at the beginning of this function: > > > > if (cpumask_empty(&scale_freq_counters_mask)) > > scale_freq_invariant = topology_scale_freq_invariant(); > > > > This will save you a call to rebuild_sched_domains_energy(), which is > > quite expensive, when cpufreq supports FIE and we also have counters. > > Good Point. > > > After comments addressed, > > > > Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> > > Thanks. > > > Tested-by: Ionela Voinescu <ionela.voinescu@arm.com> > > > -- > viresh
WARNING: multiple messages have this Message-ID (diff)
From: Ionela Voinescu <ionela.voinescu@arm.com> To: Viresh Kumar <viresh.kumar@linaro.org> Cc: Vincent Guittot <vincent.guittot@linaro.org>, linux-pm@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Rafael Wysocki <rjw@rjwysocki.net>, linux-kernel@vger.kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sudeep Holla <sudeep.holla@arm.com>, Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH V3 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback Date: Wed, 17 Feb 2021 11:30:11 +0000 [thread overview] Message-ID: <20210217113011.GA22176@arm.com> (raw) In-Reply-To: <20210217042558.o4anjdkayzgqny55@vireshk-i7> 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 + DT This testing did not yet cover patch 2/2. My checklist shows: - system invariance status correct - passed - scale factor correct (userspace cpufreq governor) - passed - arch_set_freq_scale bypassed - passed - partial "AMUs" support - failed (see below) - EAS enabling - passed I don't have an automated process for this as many test cases involve kernel source changes. In time I will automate all of these and possibly cover all scenarios with FVP (fast models) testing, but for now human error is possible :). On Wednesday 17 Feb 2021 at 09:55:58 (+0530), Viresh Kumar wrote: > 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; > > > > > > /* We are already set since the last insmod of cpufreq driver */ > > > @@ -257,25 +256,10 @@ static void amu_fie_setup(const struct cpumask *cpus) > > > > > > cpumask_or(amu_fie_cpus, amu_fie_cpus, cpus); > > > > > > - invariant = topology_scale_freq_invariant(); > > > - > > > - /* We aren't fully invariant yet */ > > > - if (!invariant && !cpumask_equal(amu_fie_cpus, cpu_present_mask)) > > > - return; > > > - > > > > You still need these checks, otherwise you could end up with only part > > of the CPUs setting a scale factor, when only part of the CPUs support > > AMUs and there is no cpufreq support for FIE. > > Both supports_scale_freq_counters() and topology_scale_freq_invariant() take > care of this now and they will keep reporting the system as invariant until the > time all the CPUs have counters (in absence of cpufreq). > Correct! > The topology_set_scale_freq_source() API is supposed to be called multiple > times, probably once for each policy and so I don't see a need of these checks > anymore. > 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: - topology_scale_freq_invariant() -> false (passed) - all CPUs should have their freq_scale unmodified (1024) - (failed) because only 2 out of 6 CPUs have a method of setting a scale factor What does happen: - arch_set_freq_tick() -> topology_set_freq_tick() will set a scale factor for [1-2] based on AMUs. This should not happen. We will end up with invariant signals for bigs and signals that are not freq invariant for littles. Ionela. > > Small(ish) optimisation at the beginning of this function: > > > > if (cpumask_empty(&scale_freq_counters_mask)) > > scale_freq_invariant = topology_scale_freq_invariant(); > > > > This will save you a call to rebuild_sched_domains_energy(), which is > > quite expensive, when cpufreq supports FIE and we also have counters. > > Good Point. > > > After comments addressed, > > > > Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> > > Thanks. > > > Tested-by: Ionela Voinescu <ionela.voinescu@arm.com> > > > -- > viresh _______________________________________________ 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:[~2021-02-17 11:39 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-28 10:48 [PATCH V3 0/2] cpufreq: cppc: Add support for frequency invariance Viresh Kumar 2021-01-28 10:48 ` Viresh Kumar 2021-01-28 10:48 ` [PATCH V3 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback Viresh Kumar 2021-01-28 10:48 ` Viresh Kumar 2021-02-03 11:45 ` Ionela Voinescu 2021-02-03 11:45 ` Ionela Voinescu 2021-02-05 9:14 ` Viresh Kumar 2021-02-05 9:14 ` Viresh Kumar 2021-02-17 0:24 ` Ionela Voinescu 2021-02-17 0:24 ` Ionela Voinescu 2021-02-17 4:25 ` Viresh Kumar 2021-02-17 4:25 ` Viresh Kumar 2021-02-17 11:30 ` Ionela Voinescu [this message] 2021-02-17 11:30 ` Ionela Voinescu 2021-02-17 11:40 ` Viresh Kumar 2021-02-17 11:40 ` Viresh Kumar 2021-02-17 11:57 ` Ionela Voinescu 2021-02-17 11:57 ` Ionela Voinescu 2021-02-18 7:23 ` Viresh Kumar 2021-02-18 7:23 ` Viresh Kumar 2021-02-18 9:33 ` Viresh Kumar 2021-02-18 9:33 ` Viresh Kumar 2021-02-18 16:36 ` Ionela Voinescu 2021-02-18 16:36 ` Ionela Voinescu 2021-02-19 4:58 ` Viresh Kumar 2021-02-19 4:58 ` Viresh Kumar 2021-02-19 9:44 ` Ionela Voinescu 2021-02-19 9:44 ` Ionela Voinescu 2021-02-19 9:48 ` Viresh Kumar 2021-02-19 9:48 ` Viresh Kumar 2021-01-28 10:48 ` [PATCH V3 2/2] cpufreq: cppc: Add support for frequency invariance Viresh Kumar 2021-01-28 10:48 ` Viresh Kumar 2021-02-18 16:35 ` Ionela Voinescu 2021-02-18 16:35 ` Ionela Voinescu 2021-02-22 11:00 ` Ionela Voinescu 2021-02-22 11:00 ` Ionela Voinescu 2021-02-22 11:04 ` Viresh Kumar 2021-02-22 11:04 ` Viresh Kumar
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=20210217113011.GA22176@arm.com \ --to=ionela.voinescu@arm.com \ --cc=catalin.marinas@arm.com \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=rjw@rjwysocki.net \ --cc=sudeep.holla@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.