Linux Power Management development
 help / color / mirror / Atom feed
From: Qais Yousef <qyousef@layalina.io>
To: Lukasz Luba <lukasz.luba@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	rafael@kernel.org, dietmar.eggemann@arm.com, rui.zhang@intel.com,
	amit.kucheria@verdurent.com, amit.kachhap@gmail.com,
	daniel.lezcano@linaro.org, viresh.kumar@linaro.org,
	len.brown@intel.com, pavel@ucw.cz, mhiramat@kernel.org,
	wvw@google.com
Subject: Re: [PATCH v5 15/23] PM: EM: Optimize em_cpu_energy() and remove division
Date: Tue, 16 Jan 2024 13:10:33 +0000	[thread overview]
Message-ID: <20240116131033.45berjhpwzc4hwr7@airbuntu> (raw)
In-Reply-To: <661068a2-7c46-4703-ba4d-5ce1cdf44b3d@arm.com>

On 01/15/24 12:36, Lukasz Luba wrote:
> 
> 
> On 1/15/24 12:21, Qais Yousef wrote:
> > On 01/10/24 13:53, Lukasz Luba wrote:
> > > 
> > > 
> > > On 1/4/24 19:23, Qais Yousef wrote:
> > > > On 01/02/24 11:47, Lukasz Luba wrote:
> > > > > > Did you see a problem or just being extra cautious here?
> > > > > 
> > > > > There is no problem, 'cost' is a private coefficient for EAS only.
> > > > 
> > > > Let me  ask differently, what goes wrong if you don't increase the resolution
> > > > here? Why is it necessary?
> > > > 
> > > 
> > > 
> > > When you have 800mW at CPU capacity 1024, then the value is small (below
> > > 1 thousand).
> > > Example:
> > > power = 800000 uW
> > > cost = 800000 / 1024 = 781
> > > 
> > > While I know from past that sometimes OPPs might have close voltage
> > > values and a rounding could occur and make some OPPs inefficient
> > > while they aren't.
> > > 
> > > This is what would happen when we have the 1x resolution:
> > > /sys/kernel/debug/energy_model/cpu4/ps:1008000/cost:551
> > > /sys/kernel/debug/energy_model/cpu4/ps:1200000/cost:644
> > > /sys/kernel/debug/energy_model/cpu4/ps:1416000/cost:744
> > > /sys/kernel/debug/energy_model/cpu4/ps:1512000/cost:851
> > > /sys/kernel/debug/energy_model/cpu4/ps:408000/cost:493
> > > /sys/kernel/debug/energy_model/cpu4/ps:600000/cost:493
> > > /sys/kernel/debug/energy_model/cpu4/ps:816000/cost:493
> > > The bottom 3 OPPs have the same 'cost' thus 2 OPPs are in-efficient,
> > > which is not true (see below).
> > > 
> > > This is what would happen when we have the 10x resolution:
> > > /sys/kernel/debug/energy_model/cpu4/ps:1008000/cost:5513
> > > /sys/kernel/debug/energy_model/cpu4/ps:1200000/cost:6443
> > > /sys/kernel/debug/energy_model/cpu4/ps:1416000/cost:7447
> > > /sys/kernel/debug/energy_model/cpu4/ps:1512000/cost:8514
> > > /sys/kernel/debug/energy_model/cpu4/ps:408000/cost:4934
> > > /sys/kernel/debug/energy_model/cpu4/ps:600000/cost:4933
> > > /sys/kernel/debug/energy_model/cpu4/ps:816000/cost:4934
> > > Here the OPP with 600MHz is more efficient than 408MHz,
> > > which is true. So only 408MHz will be marked as in-efficient OPP.
> > > 
> > > 
> > > This is what would happen when we have the 100x resolution:
> > > /sys/kernel/debug/energy_model/cpu4/ps:1008000/cost:55137
> > > /sys/kernel/debug/energy_model/cpu4/ps:1200000/cost:64433
> > > /sys/kernel/debug/energy_model/cpu4/ps:1416000/cost:74473
> > > /sys/kernel/debug/energy_model/cpu4/ps:1512000/cost:85140
> > > /sys/kernel/debug/energy_model/cpu4/ps:408000/cost:49346
> > > /sys/kernel/debug/energy_model/cpu4/ps:600000/cost:49331
> > > /sys/kernel/debug/energy_model/cpu4/ps:816000/cost:49346
> > > The higher (100x) resolution does not bring that much in
> > > practice.
> > 
> > So it seems a uW is not sufficient enough. We moved from mW because of
> > resolution already. Shall we make it nW then and multiply by 1000 always? The
> > choice of 10 looks arbitrary IMHO
> > 
> 
> No, there is no need of nW in the 'power' field for this.
> You've missed the point.

I think you're missing what I am saying. The multiplication by 10 looks like
magic value to increase resolution based on a single observation you noticed.

The feedback I am giving is that this needs to be better explained, in
a comment. And instead of multiplying by 10 multiply by 1000. Saying this is
enough based on a single observation is not adequate IMO.

Also the difference is tiny. Could you actually measure a difference in overall
power with and without this extra decimal point resolution? It might be better
to run at 816MHz and go back to idle faster. So the trade-off is not clear cut
to me.

So generally I am not keen on magic values based on single observations.
I think removing this or use 1000 is better.

AFAICT you decided that 0.1uW is worth caring about. But 0.19uW difference
isn't.

I can't see how much difference this makes in practice tbh. But using more
uniform conversion so that the cost is in nW (keep the power field in uW) makes
more sense at least.

It still raises the question whether this minuscule cost difference is actually
better taken into account. I think the perf/watt for 816MHz is much better so
skipping 600MHz as inefficient looks better to me.

  reply	other threads:[~2024-01-16 13:10 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 11:08 [PATCH v5 00/23] Introduce runtime modifiable Energy Model Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 01/23] PM: EM: Add missing newline for the message log Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 02/23] PM: EM: Refactor em_cpufreq_update_efficiencies() arguments Lukasz Luba
2023-12-17 17:58   ` Qais Yousef
2023-12-19 10:30     ` Lukasz Luba
2023-12-28 16:59       ` Qais Yousef
2024-01-02  9:40         ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 03/23] PM: EM: Find first CPU active while updating OPP efficiency Lukasz Luba
2023-12-17 17:58   ` Qais Yousef
2023-12-19 10:53     ` Lukasz Luba
2023-12-28 17:13       ` Qais Yousef
2024-01-02  9:42         ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 04/23] PM: EM: Refactor em_pd_get_efficient_state() to be more flexible Lukasz Luba
2023-12-12 18:49   ` Dietmar Eggemann
2023-12-19 10:58     ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 05/23] PM: EM: Refactor a new function em_compute_costs() Lukasz Luba
2023-12-17 17:58   ` Qais Yousef
2023-12-19 10:59     ` Lukasz Luba
2023-12-28 17:14       ` Qais Yousef
2024-01-02  9:43         ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 06/23] PM: EM: Check if the get_cost() callback is present in em_compute_costs() Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 07/23] PM: EM: Refactor how the EM table is allocated and populated Lukasz Luba
2023-12-12 18:50   ` Dietmar Eggemann
2023-12-19 13:19     ` Lukasz Luba
2023-12-17 17:59   ` Qais Yousef
2023-11-29 11:08 ` [PATCH v5 08/23] PM: EM: Introduce runtime modifiable table Lukasz Luba
2023-12-12 18:50   ` Dietmar Eggemann
2023-12-19 11:33     ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 09/23] PM: EM: Use runtime modified EM for CPUs energy estimation in EAS Lukasz Luba
2023-12-17 17:59   ` Qais Yousef
2023-12-19  4:03     ` Xuewen Yan
2023-12-19  8:32       ` Lukasz Luba
2023-12-28 17:32         ` Qais Yousef
2024-01-02 11:17           ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 10/23] PM: EM: Add API for memory allocations for new tables Lukasz Luba
2023-12-17 17:59   ` Qais Yousef
2023-12-19  8:45     ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 11/23] PM: EM: Add API for updating the runtime modifiable EM Lukasz Luba
2023-12-12 18:50   ` Dietmar Eggemann
2023-12-20  8:06     ` Lukasz Luba
2024-01-04 15:45       ` Dietmar Eggemann
2024-01-04 16:55         ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 12/23] PM: EM: Add helpers to read under RCU lock the EM table Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 13/23] PM: EM: Add performance field to struct em_perf_state Lukasz Luba
2023-12-17 18:00   ` Qais Yousef
2023-12-20  8:21     ` Lukasz Luba
2023-12-28 17:45       ` Qais Yousef
2023-11-29 11:08 ` [PATCH v5 14/23] PM: EM: Support late CPUs booting and capacity adjustment Lukasz Luba
2023-12-12 18:50   ` Dietmar Eggemann
2023-12-20  8:23     ` Lukasz Luba
2023-12-17 18:00   ` Qais Yousef
2024-01-02 11:39     ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 15/23] PM: EM: Optimize em_cpu_energy() and remove division Lukasz Luba
2023-12-12 18:50   ` Dietmar Eggemann
2023-12-20  8:42     ` Lukasz Luba
2024-01-04 16:30       ` Dietmar Eggemann
2024-01-04 16:56         ` Lukasz Luba
2023-12-28 18:06   ` Qais Yousef
2024-01-02 11:47     ` Lukasz Luba
2024-01-04 19:23       ` Qais Yousef
2024-01-10 13:53         ` Lukasz Luba
2024-01-15 12:21           ` Qais Yousef
2024-01-15 12:36             ` Lukasz Luba
2024-01-16 13:10               ` Qais Yousef [this message]
2024-01-16 15:34                 ` Lukasz Luba
2024-01-16 19:33                   ` Qais Yousef
2023-11-29 11:08 ` [PATCH v5 16/23] powercap/dtpm_cpu: Use new Energy Model interface to get table Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 17/23] powercap/dtpm_devfreq: " Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 18/23] drivers/thermal/cpufreq_cooling: Use new Energy Model interface Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 19/23] drivers/thermal/devfreq_cooling: " Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 20/23] PM: EM: Change debugfs configuration to use runtime EM table data Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 21/23] PM: EM: Remove old table Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 22/23] PM: EM: Add em_dev_compute_costs() as API for device drivers Lukasz Luba
2023-12-12 18:50   ` Dietmar Eggemann
2023-12-17 18:03     ` Qais Yousef
2023-12-18 11:56       ` Lukasz Luba
2023-12-20 11:14         ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 23/23] Documentation: EM: Update with runtime modification design Lukasz Luba
2023-12-12 18:51   ` Dietmar Eggemann
2023-12-19  9:35     ` Lukasz Luba
2023-12-19  4:42   ` Xuewen Yan
2023-12-19  8:47     ` Lukasz Luba
2023-12-19  6:22   ` Xuewen Yan
2023-12-19  9:32     ` Lukasz Luba
2023-12-20  2:08       ` Xuewen Yan
2023-12-20  7:57         ` Lukasz Luba
2023-12-12 18:48 ` [PATCH v5 00/23] Introduce runtime modifiable Energy Model Dietmar Eggemann
2023-12-13  9:23   ` Lukasz Luba
2023-12-13 11:34     ` Dietmar Eggemann
2023-12-13 11:45       ` Rafael J. Wysocki
2023-12-13 12:20         ` Lukasz Luba
2023-12-12 18:49 ` Rafael J. Wysocki
2023-12-13  9:32   ` Lukasz Luba
2023-12-13 13:40   ` Hongyan Xia
2023-12-13 13:16 ` Lukasz Luba
2023-12-17 18:22 ` Qais Yousef
2023-12-19 10:22   ` Lukasz Luba
2023-12-28 18:41     ` Qais Yousef
2024-01-02 12:12       ` Lukasz Luba

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=20240116131033.45berjhpwzc4hwr7@airbuntu \
    --to=qyousef@layalina.io \
    --cc=amit.kachhap@gmail.com \
    --cc=amit.kucheria@verdurent.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=mhiramat@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=viresh.kumar@linaro.org \
    --cc=wvw@google.com \
    /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