public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Luba <lukasz.luba@arm.com>
To: Qais Yousef <qyousef@layalina.io>
Cc: linux-kernel@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	linux-pm@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Wei Wang <wvw@google.com>, Rick Yiu <rickyiu@google.com>,
	Chung-Kai Mei <chungkai@google.com>,
	Hongyan Xia <hongyan.xia2@arm.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 1/4] sched/fair: Be less aggressive in calling cpufreq_update_util()
Date: Mon, 11 Dec 2023 07:56:09 +0000	[thread overview]
Message-ID: <8ee6425a-0a0e-4391-9fd3-8fe74c809772@arm.com> (raw)
In-Reply-To: <20231210205156.kausxdcwsydggwie@airbuntu>



On 12/10/23 20:51, Qais Yousef wrote:
> On 12/08/23 10:05, Lukasz Luba wrote:
>> Hi Qais,
>>
>> On 12/8/23 01:52, Qais Yousef wrote:
>>
>> [snip]
>>
>>> @@ -6704,14 +6677,6 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
>>>    	 */
>>>    	util_est_enqueue(&rq->cfs, p);
>>> -	/*
>>> -	 * If in_iowait is set, the code below may not trigger any cpufreq
>>> -	 * utilization updates, so do it here explicitly with the IOWAIT flag
>>> -	 * passed.
>>> -	 */
>>> -	if (p->in_iowait)
>>> -		cpufreq_update_util(rq, SCHED_CPUFREQ_IOWAIT);
>>> -
>>
>> Why this io wait boost is considered as the $subject says 'aggressive'
>> calling?
> 
> This will trigger a frequency update along with the iowait boost. Did I miss
> something?

Yes, it will change CPU freq and it was the main goal for this code
path. We have tests which check how that works on different memory
types.

Why do you want to remove it?

Did you run some tests (e.g. fio, gallery, etc) to check if you still
have a decent performance out some new ufs/nvme memories?

Beata & Dietmar have presented at LPC2021 a proposal to have a per-task
io boost, with a bit more controllable way of the trade off power vs.
performance [1]. IMO the io wait boost could evolve, not simply die.

Regards,
Lukasz

[1] https://lpc.events/event/11/contributions/1042/

  reply	other threads:[~2023-12-11  7:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08  1:52 [PATCH 0/4] sched: cpufreq: Remove uclamp max-aggregation Qais Yousef
2023-12-08  1:52 ` [PATCH 1/4] sched/fair: Be less aggressive in calling cpufreq_update_util() Qais Yousef
2023-12-08 10:05   ` Lukasz Luba
2023-12-10 20:51     ` Qais Yousef
2023-12-11  7:56       ` Lukasz Luba [this message]
2023-12-12 12:10         ` Qais Yousef
2023-12-14  8:19           ` Lukasz Luba
2023-12-11 18:47   ` Christian Loehle
2023-12-12 12:34     ` Qais Yousef
2023-12-12 13:09       ` Christian Loehle
2023-12-12 13:29         ` Qais Yousef
2023-12-12 10:46   ` Dietmar Eggemann
2023-12-12 12:35     ` Qais Yousef
2023-12-12 18:22       ` Hongyan Xia
2023-12-12 10:47   ` Hongyan Xia
2023-12-12 11:06   ` Vincent Guittot
2023-12-12 12:40     ` Qais Yousef
2023-12-29  0:25       ` Qais Yousef
2024-01-03 13:41         ` Vincent Guittot
2024-01-04 19:40           ` Qais Yousef
2023-12-18  8:51   ` Dietmar Eggemann
2023-12-17 21:44     ` Qais Yousef
2023-12-08  1:52 ` [PATCH 2/4] sched/uclamp: Remove rq max aggregation Qais Yousef
2023-12-11  0:08   ` Qais Yousef
2023-12-08  1:52 ` [PATCH 3/4] sched/schedutil: Ignore update requests for short running tasks Qais Yousef
2023-12-08 10:42   ` Hongyan Xia
2023-12-10 22:22     ` Qais Yousef
2023-12-11 11:15       ` Hongyan Xia
2023-12-12 12:23         ` Qais Yousef
2023-12-08  1:52 ` [PATCH 4/4] sched/documentation: Remove reference to max aggregation Qais Yousef
2023-12-18  8:19 ` [PATCH 0/4] sched: cpufreq: Remove uclamp max-aggregation Dietmar Eggemann
2023-12-17 21:23   ` Qais Yousef

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=8ee6425a-0a0e-4391-9fd3-8fe74c809772@arm.com \
    --to=lukasz.luba@arm.com \
    --cc=chungkai@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=hongyan.xia2@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qyousef@layalina.io \
    --cc=rafael@kernel.org \
    --cc=rickyiu@google.com \
    --cc=vincent.guittot@linaro.org \
    --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