All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: rjw@rjwysocki.net, viresh.kumar@linaro.org,
	dietmar.eggemann@arm.com, catalin.marinas@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 v5 5/5] arch_topology, arm, arm64: define arch_scale_freq_invariant()
Date: Wed, 2 Sep 2020 14:24:28 +0100	[thread overview]
Message-ID: <20200902132428.GD25462@bogus> (raw)
In-Reply-To: <20200901205549.30096-6-ionela.voinescu@arm.com>

On Tue, Sep 01, 2020 at 09:55:49PM +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>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>

Reviewed-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: linux-pm@vger.kernel.org, viresh.kumar@linaro.org,
	rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
	dietmar.eggemann@arm.com, catalin.marinas@arm.com,
	will@kernel.org, valentin.schneider@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 5/5] arch_topology, arm, arm64: define arch_scale_freq_invariant()
Date: Wed, 2 Sep 2020 14:24:28 +0100	[thread overview]
Message-ID: <20200902132428.GD25462@bogus> (raw)
In-Reply-To: <20200901205549.30096-6-ionela.voinescu@arm.com>

On Tue, Sep 01, 2020 at 09:55:49PM +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>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>

Reviewed-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

  reply	other threads:[~2020-09-02 14:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01 20:55 [PATCH v5 0/5] cpufreq: improve frequency invariance support Ionela Voinescu
2020-09-01 20:55 ` Ionela Voinescu
2020-09-01 20:55 ` [PATCH v5 1/5] arch_topology: validate input frequencies to arch_set_freq_scale() Ionela Voinescu
2020-09-01 20:55   ` Ionela Voinescu
2020-09-02 13:32   ` Sudeep Holla
2020-09-02 13:32     ` Sudeep Holla
2020-09-01 20:55 ` [PATCH v5 2/5] cpufreq: move invariance setter calls in cpufreq core Ionela Voinescu
2020-09-01 20:55   ` Ionela Voinescu
2020-09-02 13:30   ` Sudeep Holla
2020-09-02 13:30     ` Sudeep Holla
2020-09-01 20:55 ` [PATCH v5 3/5] cpufreq: report whether cpufreq supports Frequency Invariance (FI) Ionela Voinescu
2020-09-01 20:55   ` Ionela Voinescu
2020-09-02 13:28   ` Sudeep Holla
2020-09-02 13:28     ` Sudeep Holla
2020-09-03 13:45     ` Ionela Voinescu
2020-09-03 13:45       ` Ionela Voinescu
2020-09-03 14:19       ` Sudeep Holla
2020-09-03 14:19         ` Sudeep Holla
2020-09-01 20:55 ` [PATCH v5 4/5] arch_topology, cpufreq: constify arch_* cpumasks Ionela Voinescu
2020-09-01 20:55   ` Ionela Voinescu
2020-09-02 13:25   ` Sudeep Holla
2020-09-02 13:25     ` Sudeep Holla
2020-09-01 20:55 ` [PATCH v5 5/5] arch_topology, arm, arm64: define arch_scale_freq_invariant() Ionela Voinescu
2020-09-01 20:55   ` Ionela Voinescu
2020-09-02 13:24   ` Sudeep Holla [this message]
2020-09-02 13:24     ` Sudeep Holla
2020-09-03 13:32 ` [PATCH v5 0/5] cpufreq: improve frequency invariance support Ionela Voinescu
2020-09-03 13:32   ` Ionela Voinescu
2020-09-04  4:38   ` Viresh Kumar
2020-09-04  4:38     ` Viresh Kumar
2020-09-18 17:12     ` Rafael J. Wysocki
2020-09-18 17:12       ` Rafael J. Wysocki

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=20200902132428.GD25462@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-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --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.