public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Qais Yousef <qyousef@layalina.io>
To: Lukasz Luba <lukasz.luba@arm.com>
Cc: Kajetan Puchalski <kajetan.puchalski@arm.com>,
	rafael@kernel.org, daniel.lezcano@linaro.org,
	Dietmar.Eggemann@arm.com, dsmythies@telus.net,
	yu.chen.surf@gmail.com, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Todd Kjos <tkjos@google.com>, "wvw@google.com" <wvw@google.com>
Subject: Re: [PATCH v6 2/2] cpuidle: teo: Introduce util-awareness
Date: Sun, 16 Jun 2024 22:48:12 +0100	[thread overview]
Message-ID: <20240616214812.nxtz2kt3svo44mbe@airbuntu> (raw)
In-Reply-To: <d539bd2c-89f9-4a04-900c-41d257123163@arm.com>

On 06/12/24 08:53, Lukasz Luba wrote:

> > This won't help. We tried different values, unfortunately the logic is flawed.
> > Utilization value on its own says nothing about the idleness of the system.
> 
> This is not true. When you up-migrate a task to big CPU, then CPU idle
> gov can instantly benefit from utilization information and won't make
> mistake based on old local history and won't use deep idle state.
> So migrating the utilization from one CPU to another CPU says a lot
> about the idleness to that destination CPU.

You can migrate a 1024 tasks to a bigger core, but it could run for 3ms and
sleep for 40ms. So unfortunately I have to disagree with you here.
Generally a high util value doesn't mean we are not going to be idle long
enough to satisfy min_residency of the CPU.

> When Christian removed the util he got -4.5% lower score in GB5, so
> this util has impact [1].

We need the idle governor to help with power saving. We can disable DVFS and
all idle states and always get a better performance.

The residency is ~50% worse on some clusters with this change. Overall power
impact is 2-4% in many use cases.

GB5 is not really a representative use case to measure the usefulness of the
idle governor. Task placement to avoid the cost of idle exit latency is
a completely different problem.

  reply	other threads:[~2024-06-16 21:48 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 14:51 [PATCH v6 0/2] cpuidle: teo: Introduce util-awareness Kajetan Puchalski
2023-01-05 14:51 ` [PATCH v6 1/2] cpuidle: teo: Optionally skip polling states in teo_find_shallower_state() Kajetan Puchalski
2023-01-05 14:51 ` [PATCH v6 2/2] cpuidle: teo: Introduce util-awareness Kajetan Puchalski
2023-01-05 15:07   ` Rafael J. Wysocki
2023-01-05 15:20     ` Lukasz Luba
2023-01-05 15:34     ` Vincent Guittot
2023-01-05 17:11       ` Rafael J. Wysocki
2023-07-11 17:58   ` Qais Yousef
2023-07-17 13:47     ` Lukasz Luba
2023-07-17 18:21       ` Qais Yousef
2023-07-18 10:23         ` Lukasz Luba
2023-07-18 12:45           ` Qais Yousef
2023-07-18 12:02     ` Kajetan Puchalski
2023-07-18 13:24       ` Qais Yousef
2023-07-19 15:07         ` Kajetan Puchalski
2023-09-17  1:05         ` Qais Yousef
2023-09-18 11:41           ` Kajetan Puchalski
2023-09-19  0:04             ` Qais Yousef
2024-05-28  9:29           ` Vincent Guittot
2024-05-28  9:59             ` Lukasz Luba
2024-05-28 14:07               ` Vincent Guittot
2024-05-29 13:09                 ` Christian Loehle
2024-05-31  8:57                   ` Vincent Guittot
2024-06-12  7:25                 ` Lukasz Luba
2024-06-12  9:04                   ` Vincent Guittot
2024-06-12  9:17                     ` Lukasz Luba
2024-06-17  8:52                       ` Vincent Guittot
2024-06-19 12:20                       ` Lukasz Luba
2024-05-28 10:35             ` Christian Loehle
2024-05-28 12:12             ` Kajetan Puchalski
2024-05-29 10:23               ` Qais Yousef
2024-05-29 10:19             ` Qais Yousef
2024-06-12  7:53               ` Lukasz Luba
2024-06-16 21:48                 ` Qais Yousef [this message]
2024-06-17  8:13                   ` Lukasz Luba
2023-01-12 19:22 ` [PATCH v6 0/2] " Rafael J. Wysocki
2023-01-13 15:21   ` Kajetan Puchalski

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=20240616214812.nxtz2kt3svo44mbe@airbuntu \
    --to=qyousef@layalina.io \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dsmythies@telus.net \
    --cc=kajetan.puchalski@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=tkjos@google.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@linaro.org \
    --cc=wvw@google.com \
    --cc=yu.chen.surf@gmail.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