All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/3] arch_topology: Correct CPU capacity scaling
Date: Mon, 14 Mar 2022 18:10:58 +0000	[thread overview]
Message-ID: <Yi+FMrG9NyBnMX0i@arm.com> (raw)
In-Reply-To: <20220313055512.248571-1-leo.yan@linaro.org>

Hi Leo,

On Sunday 13 Mar 2022 at 13:55:09 (+0800), Leo Yan wrote:
> This patch set is to address issues for CPU capacity scaling.
> 
> "capacity-dmips-mhz" property might be absent in all CPU nodes, and in
> another situation, DT might have inconsistent binding issue, e.g. some
> CPU nodes have "capacity-dmips-mhz" property and some nodes miss the
> property.  Current code mixes these two cases and always rollback to CPU
> capacity 1024 for these two cases.
> 
> Patches 01 and 02 in this set are used to distinguish the two different
> DT binding cases, and for the inconsistent binding issue, it rolls back
> to 1024 without CPU capacity scaling.
> 
> Patch 03 is to handle the case for absenting "capacity-dmips-mhz"
> property in CPU nodes, the patch proceeds to do CPU capacity scaling based
> on CPU maximum capacity.  Thus it can reflect the correct CPU capacity for
> Arm platforms with "fast" and "slow" clusters (CPUs in two clusters have
> the same raw capacity but with different maximum frequencies).
> 

In my opinion it's difficult to handle absent "capacity-dmips-mhz"
properties, as they can be a result of 3 scenarios: potential..
 1. bug in DT
 2. unwillingness to fill this information in DT
 3. suggestion that we're dealing with CPUs with same u-arch
    (same capacity-dmips-mhz)

I'm not sure it's up to us to interpret suggestions in the code so I
believe treating missing information as error is the right choice, which
is how we're handling this now.

For 3. (and patch 03), isn't it easier to populate capacity-dmips-mhz to
the same value (say 1024) in DT? That is a clear message that we're
dealing with CPUs with the same u-arch.

Thanks,
Ionela.


> This patch set is applied on the mainline kernel with the latest commit
> 68453767131a ("ARM: Spectre-BHB: provide empty stub for non-config").
> And tested on Arm64 Hikey960 platform (with a bit hacking to emulate
> fast and slow clusters).
> 
> 
> Leo Yan (3):
>   arch_topology: Correct semantics for 'cap_parsing_failed'
>   arch_topology: Handle inconsistent binding of CPU raw capacity
>   arch_topology: Scale CPU capacity if without CPU raw capacity
> 
>  drivers/base/arch_topology.c | 42 +++++++++++++++++++++++++++++-------
>  1 file changed, 34 insertions(+), 8 deletions(-)
> 
> -- 
> 2.25.1
> 
> 

  parent reply	other threads:[~2022-03-14 18:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-13  5:55 [PATCH v1 0/3] arch_topology: Correct CPU capacity scaling Leo Yan
2022-03-13  5:55 ` [PATCH v1 1/3] arch_topology: Correct semantics for 'cap_parsing_failed' Leo Yan
2022-03-13  5:55 ` [PATCH v1 2/3] arch_topology: Handle inconsistent binding of CPU raw capacity Leo Yan
2022-03-13  5:55 ` [PATCH v1 3/3] arch_topology: Scale CPU capacity if without " Leo Yan
2022-03-14 18:10 ` Ionela Voinescu [this message]
2022-03-15  3:29   ` [PATCH v1 0/3] arch_topology: Correct CPU capacity scaling Leo Yan
2022-03-15 10:08     ` Sudeep Holla
2022-03-15 14:59       ` Leo Yan
2022-03-15  9:49   ` Sudeep Holla

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=Yi+FMrG9NyBnMX0i@arm.com \
    --to=ionela.voinescu@arm.com \
    --cc=bryan.odonoghue@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.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.