linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Lukasz Luba <lukasz.luba@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org
Cc: sudeep.holla@arm.com, cristian.marussi@arm.com,
	viresh.kumar@linaro.org, rjw@rjwysocki.net
Subject: Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers
Date: Tue, 4 Aug 2020 10:27:13 -0700	[thread overview]
Message-ID: <a3354ae8-f40f-83f2-d6eb-7f588af75e97@gmail.com> (raw)
In-Reply-To: <20200729151208.27737-1-lukasz.luba@arm.com>



On 7/29/2020 8:12 AM, Lukasz Luba wrote:
> Hi all,
> 
> The existing CPUFreq framework does not tracks the statistics when the
> 'fast switch' is used or when firmware changes the frequency independently
> due to e.g. thermal reasons. However, the firmware might track the frequency
> changes and expose this to the kernel.

Or the firmware might have changed the CPU frequency in response to a
request from the secure world for instance.

> 
> This patch set aims to introduce CPUfreq statistics gathered by firmware
> and retrieved by CPUFreq driver. It would require a new API functions
> in the CPUFreq, which allows to poke drivers to get these stats.

From a debugging perspective, it would be helpful if the firmware
maintained statistics were exposed as a super-set of the Linux cpufreq
statistics and aggregated into them such that you could view the normal
world vs. secure world residency of a given frequency point. This would
help because a lot of times, Linux requests freq X, but the secure world
requires freq Y (with X >= Y) and people do not really understand why
the resulting power usage is higher for instance.

What are your thoughts on this?
-- 
Florian

  parent reply	other threads:[~2020-08-04 17:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 15:12 [PATCH 0/4] CPUFreq statistics retrieved by drivers Lukasz Luba
2020-07-29 15:12 ` [PATCH 1/4] cpufreq: Add support for statistics read from drivers Lukasz Luba
2020-07-29 15:12 ` [PATCH 2/4] scmi: perf: Extend protocol to support performance statistics Lukasz Luba
2020-07-31  1:50   ` kernel test robot
2020-07-31 15:15   ` Cristian Marussi
2020-08-04 11:10     ` Lukasz Luba
2020-07-29 15:12 ` [PATCH 3/4] cpufreq: scmi: Move scmi_cpufreq_driver structure to the top Lukasz Luba
2020-07-29 15:12 ` [PATCH 4/4] cpufreq: scmi: Read statistics from FW shared memory Lukasz Luba
2020-07-30  8:53 ` [PATCH 0/4] CPUFreq statistics retrieved by drivers Viresh Kumar
2020-07-30  9:10   ` Sudeep Holla
2020-07-30  9:36     ` Lukasz Luba
2020-07-31 15:56       ` Sudeep Holla
2020-08-04 17:19         ` Florian Fainelli
2020-08-05 12:36           ` Sudeep Holla
2020-08-04  5:35       ` Viresh Kumar
2020-08-04 10:29         ` Lukasz Luba
2020-08-04 10:38           ` Viresh Kumar
2020-08-04 10:44             ` Lukasz Luba
2020-09-02  7:26               ` Viresh Kumar
2020-08-04 17:27 ` Florian Fainelli [this message]
2020-08-05 11:04   ` Lukasz Luba
2020-08-05 13:04     ` Viresh Kumar
2020-08-05 16:03       ` Sudeep Holla
2020-08-05 17:33         ` Florian Fainelli
2020-08-06 13:37           ` 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=a3354ae8-f40f-83f2-d6eb-7f588af75e97@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=cristian.marussi@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=sudeep.holla@arm.com \
    --cc=viresh.kumar@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 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).