devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Nicola Mazzucato <nicola.mazzucato@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	devicetree@vger.kernel.org, sudeep.holla@arm.com,
	rjw@rjwysocki.net, vireshk@kernel.org, robh+dt@kernel.org,
	sboyd@kernel.org, nm@ti.com, daniel.lezcano@linaro.org,
	morten.rasmussen@arm.com, chris.redpath@arm.com
Subject: Re: [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies
Date: Fri, 6 Nov 2020 14:50:20 +0530	[thread overview]
Message-ID: <20201106092020.za3oxg7gutzc3y2b@vireshk-i7> (raw)
In-Reply-To: <20201102120115.29993-4-nicola.mazzucato@arm.com>

On 02-11-20, 12:01, Nicola Mazzucato wrote:
> This is a continuation of the previous v2, where we focused mostly on the
> dt binding.
> 
> I am seeking some feedback/comments on the following two approaches.
> 
> Intro:
> We have seen that in a system where performance control and hardware
> description do not match (i.e. per-cpu), we still need the information of
> how the v/f lines are shared among the cpus. We call this information
> "performance dependencies".
> We got this info through the opp-shared (the previous 2 patches aim for
> that).
> 
> Problem:
> How do we share such info (retrieved from a cpufreq driver) to other
> consumers that rely on it? I have two proposals.

I haven't really stop thinking about what and how we should solve
this, but I have few concerns first.

> 2) drivers/thermal/cpufreq_cooling: Replace related_cpus with dependent_cpus

I am not sure if I understand completely on how this is going to be
modified/work.

The only use of related_cpus in the cooling driver is in the helper
cdev->get_requested_power(), where we need to find the total power
being consumed by devices controlled by the cooling device. Right ?

Now the cooling devices today are very closely related to the cpufreq
policy, the registration function itself takes a cpufreq policy as an
argument.

Consider that you have an octa-core platform and all the CPUs are
dependent on each other. With your suggested changes and hw control,
we will have different cpufreq policies for each CPU. And so we will
have a cooling device, cdev, for each CPU as well. When the IPA
governor calls cdev->get_requested_power(), why should we ever bother
to traverse the list of dependent_cpus and not related_cpus only ?

Otherwise the same CPU will have its load contributed to the power of
8 cooling devices.

-- 
viresh

  reply	other threads:[~2020-11-06  9:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02 12:01 [PATCH v3 0/3] CPUFreq: Add support for cpu performance dependencies Nicola Mazzucato
2020-11-02 12:01 ` [PATCH v3 1/3] dt-bindings/opp: Update documentation for opp-shared Nicola Mazzucato
2020-11-02 12:01 ` [PATCH v3 2/3] opp/of: Allow empty opp-table with opp-shared Nicola Mazzucato
2020-11-03  5:01   ` Viresh Kumar
2020-11-04 17:54     ` Nicola Mazzucato
2020-11-05  4:41       ` Viresh Kumar
2020-11-16 11:45         ` Nicola Mazzucato
2020-11-02 12:01 ` [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies Nicola Mazzucato
2020-11-06  9:20   ` Viresh Kumar [this message]
2020-11-06 10:37     ` Lukasz Luba
2020-11-06 10:55       ` Viresh Kumar
2020-11-06 11:14         ` Lukasz Luba
2020-11-09  6:57           ` Viresh Kumar
2020-11-16 11:33             ` Lukasz Luba
2020-11-17 10:11               ` Viresh Kumar
2020-11-17 10:47                 ` Nicola Mazzucato
2020-11-17 10:53                   ` Viresh Kumar
2020-11-17 13:06                     ` Rafael J. Wysocki
2020-11-18  4:42                       ` Viresh Kumar
2020-11-18 12:00                         ` Rafael J. Wysocki
2020-11-19  6:40                           ` Viresh Kumar
2020-11-17 10:47                 ` Lukasz Luba
2020-11-17 10:55                   ` Viresh Kumar
2020-11-06  9:24   ` Viresh Kumar
2020-11-19  6:43   ` Viresh Kumar
2020-11-03 10:18 ` [PATCH v3 0/3] CPUFreq: Add support for cpu performance dependencies Viresh Kumar
2020-11-04 18:04   ` Nicola Mazzucato
2020-11-05 14:25     ` Vincent Guittot
2020-11-05 15:46       ` Ionela Voinescu

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=20201106092020.za3oxg7gutzc3y2b@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=chris.redpath@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=nicola.mazzucato@arm.com \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vireshk@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).