All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: rjw@rjwysocki.net, dietmar.eggemann@arm.com,
	catalin.marinas@arm.com, sudeep.holla@arm.com, will@kernel.org,
	valentin.schneider@arm.com, linux-pm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 5/5] arch_topology, arm, arm64: define arch_scale_freq_invariant()
Date: Tue, 25 Aug 2020 13:20:57 +0530	[thread overview]
Message-ID: <20200825075057.rpeg6d6uziqzogsa@vireshk-i7> (raw)
In-Reply-To: <20200824210252.27486-6-ionela.voinescu@arm.com>

On 24-08-20, 22:02, 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>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  arch/arm/include/asm/topology.h   | 1 +
>  arch/arm64/include/asm/topology.h | 1 +
>  arch/arm64/kernel/topology.c      | 7 +++++++
>  drivers/base/arch_topology.c      | 6 ++++++
>  include/linux/arch_topology.h     | 2 ++
>  5 files changed, 17 insertions(+)
> 
> diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
> index e0593cf095d0..9219e67befbe 100644
> --- a/arch/arm/include/asm/topology.h
> +++ b/arch/arm/include/asm/topology.h
> @@ -9,6 +9,7 @@
>  
>  /* Replace task scheduler's default frequency-invariant accounting */
>  #define arch_scale_freq_capacity topology_get_freq_scale
> +#define arch_scale_freq_invariant topology_scale_freq_invariant

Maybe this macro should have been named arch_is_freq_invariant as all other ones
are actually getting us a scaled number and this one is just a flag. But yeah,
that is out of this series's scope, but maybe you should name
topology_scale_freq_invariant() to topology_is_freq_invariant() or something
else on those lines ? Anyway:

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: linux-pm@vger.kernel.org, catalin.marinas@arm.com,
	rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
	dietmar.eggemann@arm.com, sudeep.holla@arm.com, will@kernel.org,
	valentin.schneider@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 5/5] arch_topology, arm, arm64: define arch_scale_freq_invariant()
Date: Tue, 25 Aug 2020 13:20:57 +0530	[thread overview]
Message-ID: <20200825075057.rpeg6d6uziqzogsa@vireshk-i7> (raw)
In-Reply-To: <20200824210252.27486-6-ionela.voinescu@arm.com>

On 24-08-20, 22:02, 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>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  arch/arm/include/asm/topology.h   | 1 +
>  arch/arm64/include/asm/topology.h | 1 +
>  arch/arm64/kernel/topology.c      | 7 +++++++
>  drivers/base/arch_topology.c      | 6 ++++++
>  include/linux/arch_topology.h     | 2 ++
>  5 files changed, 17 insertions(+)
> 
> diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
> index e0593cf095d0..9219e67befbe 100644
> --- a/arch/arm/include/asm/topology.h
> +++ b/arch/arm/include/asm/topology.h
> @@ -9,6 +9,7 @@
>  
>  /* Replace task scheduler's default frequency-invariant accounting */
>  #define arch_scale_freq_capacity topology_get_freq_scale
> +#define arch_scale_freq_invariant topology_scale_freq_invariant

Maybe this macro should have been named arch_is_freq_invariant as all other ones
are actually getting us a scaled number and this one is just a flag. But yeah,
that is out of this series's scope, but maybe you should name
topology_scale_freq_invariant() to topology_is_freq_invariant() or something
else on those lines ? Anyway:

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-08-25  7:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-24 21:02 [PATCH v3 0/5] cpufreq: improve frequency invariance support Ionela Voinescu
2020-08-24 21:02 ` Ionela Voinescu
2020-08-24 21:02 ` [PATCH v3 1/5] arch_topology: validate input frequencies to arch_set_freq_scale() Ionela Voinescu
2020-08-24 21:02   ` Ionela Voinescu
2020-08-25  5:56   ` Viresh Kumar
2020-08-25  5:56     ` Viresh Kumar
2020-08-25 11:31     ` Ionela Voinescu
2020-08-25 11:31       ` Ionela Voinescu
2020-08-27  6:10       ` Viresh Kumar
2020-08-27  6:10         ` Viresh Kumar
2020-08-24 21:02 ` [PATCH v3 2/5] cpufreq: move invariance setter calls in cpufreq core Ionela Voinescu
2020-08-24 21:02   ` Ionela Voinescu
2020-08-25  6:03   ` Viresh Kumar
2020-08-25  6:03     ` Viresh Kumar
2020-08-24 21:02 ` [PATCH v3 3/5] cpufreq: report whether cpufreq supports Frequency Invariance (FI) Ionela Voinescu
2020-08-24 21:02   ` Ionela Voinescu
2020-08-25  6:27   ` Viresh Kumar
2020-08-25  6:27     ` Viresh Kumar
2020-08-25 11:07     ` Ionela Voinescu
2020-08-25 11:07       ` Ionela Voinescu
2020-08-24 21:02 ` [PATCH v3 4/5] arch_topology, cpufreq: constify arch_* cpumasks Ionela Voinescu
2020-08-24 21:02   ` Ionela Voinescu
2020-08-25  6:27   ` Viresh Kumar
2020-08-25  6:27     ` Viresh Kumar
2020-08-24 21:02 ` [PATCH v3 5/5] arch_topology, arm, arm64: define arch_scale_freq_invariant() Ionela Voinescu
2020-08-24 21:02   ` Ionela Voinescu
2020-08-25  7:50   ` Viresh Kumar [this message]
2020-08-25  7:50     ` 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=20200825075057.rpeg6d6uziqzogsa@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=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=rjw@rjwysocki.net \
    --cc=sudeep.holla@arm.com \
    --cc=valentin.schneider@arm.com \
    --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.