From: Catalin Marinas <catalin.marinas@arm.com>
To: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: rjw@rjwysocki.net, viresh.kumar@linaro.org,
dietmar.eggemann@arm.com, sudeep.holla@arm.com, will@kernel.org,
linux@armlinux.org.uk, mingo@redhat.com, peterz@infradead.org,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Valentin Schneider <valentin.schneider@arm.com>
Subject: Re: [PATCH v2 6/7] arch_topology,arm,arm64: define arch_scale_freq_invariant()
Date: Thu, 30 Jul 2020 12:44:48 +0100 [thread overview]
Message-ID: <20200730114447.GK25149@gaia> (raw)
In-Reply-To: <20200722093732.14297-7-ionela.voinescu@arm.com>
On Wed, Jul 22, 2020 at 10:37:31AM +0100, Ionela Voinescu wrote:
> From: Valentin Schneider <valentin.schneider@arm.com>
>
> arch_scale_freq_invariant() is used by schedutil to determine whether
> the scheduler's load-tracking signals are frequency invariant. Its
> definition is overridable, though by default it is hardcoded to 'true'
> if arch_scale_freq_capacity() is defined ('false' otherwise).
>
> This behaviour is not overridden on arm, arm64 and other users of the
> generic arch topology driver, which is somewhat precarious:
> arch_scale_freq_capacity() will always be defined, yet not all cpufreq
> drivers are guaranteed to drive the frequency invariance scale factor
> setting. In other words, the load-tracking signals may very well *not*
> be frequency invariant.
>
> Now that cpufreq can be queried on whether the current driver is driving
> the Frequency Invariance (FI) scale setting, the current situation can
> be improved. This combines the query of whether cpufreq supports the
> setting of the frequency scale factor, with whether all online CPUs are
> counter-based FI enabled.
>
> While cpufreq FI enablement applies at system level, for all CPUs,
> counter-based FI support could also be used for only a subset of CPUs to
> set the invariance scale factor. Therefore, if cpufreq-based FI support
> is present, we consider the system to be invariant. If missing, we
> require all online CPUs to be counter-based FI enabled in order for the
> full system to be considered invariant.
>
> If the system ends up not being invariant, a new condition is needed in
> the counter initialization code that disables all scale factor setting
> based on counters.
>
> Precedence of counters over cpufreq use is not important here. The
> invariant status is only given to the system if all CPUs have at least
> one method of setting the frequency scale factor.
>
> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: linux-pm@vger.kernel.org, peterz@infradead.org,
viresh.kumar@linaro.org,
Valentin Schneider <valentin.schneider@arm.com>,
rjw@rjwysocki.net, linux@armlinux.org.uk,
linux-kernel@vger.kernel.org, mingo@redhat.com,
sudeep.holla@arm.com, will@kernel.org, dietmar.eggemann@arm.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 6/7] arch_topology,arm,arm64: define arch_scale_freq_invariant()
Date: Thu, 30 Jul 2020 12:44:48 +0100 [thread overview]
Message-ID: <20200730114447.GK25149@gaia> (raw)
In-Reply-To: <20200722093732.14297-7-ionela.voinescu@arm.com>
On Wed, Jul 22, 2020 at 10:37:31AM +0100, Ionela Voinescu wrote:
> From: Valentin Schneider <valentin.schneider@arm.com>
>
> arch_scale_freq_invariant() is used by schedutil to determine whether
> the scheduler's load-tracking signals are frequency invariant. Its
> definition is overridable, though by default it is hardcoded to 'true'
> if arch_scale_freq_capacity() is defined ('false' otherwise).
>
> This behaviour is not overridden on arm, arm64 and other users of the
> generic arch topology driver, which is somewhat precarious:
> arch_scale_freq_capacity() will always be defined, yet not all cpufreq
> drivers are guaranteed to drive the frequency invariance scale factor
> setting. In other words, the load-tracking signals may very well *not*
> be frequency invariant.
>
> Now that cpufreq can be queried on whether the current driver is driving
> the Frequency Invariance (FI) scale setting, the current situation can
> be improved. This combines the query of whether cpufreq supports the
> setting of the frequency scale factor, with whether all online CPUs are
> counter-based FI enabled.
>
> While cpufreq FI enablement applies at system level, for all CPUs,
> counter-based FI support could also be used for only a subset of CPUs to
> set the invariance scale factor. Therefore, if cpufreq-based FI support
> is present, we consider the system to be invariant. If missing, we
> require all online CPUs to be counter-based FI enabled in order for the
> full system to be considered invariant.
>
> If the system ends up not being invariant, a new condition is needed in
> the counter initialization code that disables all scale factor setting
> based on counters.
>
> Precedence of counters over cpufreq use is not important here. The
> invariant status is only given to the system if all CPUs have at least
> one method of setting the frequency scale factor.
>
> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
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-07-30 11:44 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 9:37 [PATCH v2 0/7] cpufreq: improve frequency invariance support Ionela Voinescu
2020-07-22 9:37 ` Ionela Voinescu
2020-07-22 9:37 ` [PATCH v2 1/7] cpufreq: move invariance setter calls in cpufreq core Ionela Voinescu
2020-07-22 9:37 ` Ionela Voinescu
2020-07-27 13:48 ` Rafael J. Wysocki
2020-07-27 13:48 ` Rafael J. Wysocki
2020-07-29 9:03 ` Ionela Voinescu
2020-07-29 9:03 ` Ionela Voinescu
2020-07-30 3:41 ` Viresh Kumar
2020-07-30 3:41 ` Viresh Kumar
2020-08-03 13:26 ` Ionela Voinescu
2020-08-03 13:26 ` Ionela Voinescu
2020-08-03 13:46 ` Rafael J. Wysocki
2020-08-03 13:46 ` Rafael J. Wysocki
2020-08-03 14:16 ` Ionela Voinescu
2020-08-03 14:16 ` Ionela Voinescu
2020-07-22 9:37 ` [PATCH v2 2/7] cpufreq: set invariance scale factor on transition end Ionela Voinescu
2020-07-22 9:37 ` Ionela Voinescu
2020-07-27 13:52 ` Rafael J. Wysocki
2020-07-27 13:52 ` Rafael J. Wysocki
2020-07-29 9:14 ` Ionela Voinescu
2020-07-29 9:14 ` Ionela Voinescu
2020-07-30 4:13 ` Viresh Kumar
2020-07-30 4:13 ` Viresh Kumar
2020-08-03 13:58 ` Ionela Voinescu
2020-08-03 13:58 ` Ionela Voinescu
2020-08-04 6:26 ` Viresh Kumar
2020-08-04 6:26 ` Viresh Kumar
2020-08-05 10:35 ` Ionela Voinescu
2020-08-05 10:35 ` Ionela Voinescu
2020-07-22 9:37 ` [PATCH v2 3/7] arch_topology: disable frequency invariance for CONFIG_BL_SWITCHER Ionela Voinescu
2020-07-22 9:37 ` Ionela Voinescu
2020-07-30 4:24 ` Viresh Kumar
2020-07-30 4:24 ` Viresh Kumar
2020-07-30 10:29 ` Dietmar Eggemann
2020-07-30 10:29 ` Dietmar Eggemann
2020-07-31 15:48 ` Sudeep Holla
2020-07-31 15:48 ` Sudeep Holla
2020-08-03 14:39 ` Ionela Voinescu
2020-08-03 14:39 ` Ionela Voinescu
2020-08-04 6:30 ` Viresh Kumar
2020-08-04 6:30 ` Viresh Kumar
2020-08-10 9:01 ` Ionela Voinescu
2020-08-10 9:01 ` Ionela Voinescu
2020-07-22 9:37 ` [PATCH v2 4/7] cpufreq: report whether cpufreq supports Frequency Invariance (FI) Ionela Voinescu
2020-07-22 9:37 ` Ionela Voinescu
2020-07-27 14:02 ` Rafael J. Wysocki
2020-07-27 14:02 ` Rafael J. Wysocki
2020-07-29 14:39 ` Ionela Voinescu
2020-07-29 14:39 ` Ionela Voinescu
2020-07-30 4:43 ` Viresh Kumar
2020-07-30 4:43 ` Viresh Kumar
2020-08-03 15:24 ` Ionela Voinescu
2020-08-03 15:24 ` Ionela Voinescu
2020-08-04 6:46 ` Viresh Kumar
2020-08-04 6:46 ` Viresh Kumar
2020-08-05 10:35 ` Ionela Voinescu
2020-08-05 10:35 ` Ionela Voinescu
2020-07-22 9:37 ` [PATCH v2 5/7] arch_topology,cpufreq,sched/core: constify arch_* cpumasks Ionela Voinescu
2020-07-22 9:37 ` [PATCH v2 5/7] arch_topology, cpufreq, sched/core: " Ionela Voinescu
2020-07-30 11:43 ` [PATCH v2 5/7] arch_topology,cpufreq,sched/core: " Catalin Marinas
2020-07-30 11:43 ` [PATCH v2 5/7] arch_topology, cpufreq, sched/core: " Catalin Marinas
2020-07-22 9:37 ` [PATCH v2 6/7] arch_topology,arm,arm64: define arch_scale_freq_invariant() Ionela Voinescu
2020-07-22 9:37 ` [PATCH v2 6/7] arch_topology, arm, arm64: " Ionela Voinescu
2020-07-30 11:44 ` Catalin Marinas [this message]
2020-07-30 11:44 ` [PATCH v2 6/7] arch_topology,arm,arm64: " Catalin Marinas
2020-07-22 9:37 ` [PATCH v2 7/7] cpufreq: make schedutil the default for arm and arm64 Ionela Voinescu
2020-07-22 9:37 ` Ionela Voinescu
2020-07-30 4:54 ` Viresh Kumar
2020-07-30 4:54 ` 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=20200730114447.GK25149@gaia \
--to=catalin.marinas@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=ionela.voinescu@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=valentin.schneider@arm.com \
--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: link
Be 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.