From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Xuewen Yan <xuewen.yan94@gmail.com>
Cc: Xuewen Yan <xuewen.yan@unisoc.com>,
vincent.guittot@linaro.org, mingo@redhat.com,
peterz@infradead.org, juri.lelli@redhat.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, vincent.donnefort@arm.com,
qyousef@layalina.io, ke.wang@unisoc.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/fair: Prevent cpu_busy_time from exceeding actual_cpu_capacity
Date: Fri, 21 Jun 2024 12:22:07 +0200 [thread overview]
Message-ID: <e2fdb89d-7594-4025-8e20-299dddc80497@arm.com> (raw)
In-Reply-To: <CAB8ipk-86-oJJ2XhJ2y5=ek3QwmMe0OJ+ry9FddmXrrChqu6+A@mail.gmail.com>
On 07/06/2024 12:37, Xuewen Yan wrote:
> On Fri, Jun 7, 2024 at 6:30 PM Dietmar Eggemann
> <dietmar.eggemann@arm.com> wrote:
>>
>> On 07/06/2024 10:20, Xuewen Yan wrote:
>>> Hi Dietmar
>>>
>>> On Fri, Jun 7, 2024 at 3:19 PM Dietmar Eggemann
>>> <dietmar.eggemann@arm.com> wrote:
>>>>
>>>> On 06/06/2024 09:06, Xuewen Yan wrote:
>>>>> Because the effective_cpu_util() would return a util which
>>>>> maybe bigger than the actual_cpu_capacity, this could cause
>>>>> the pd_busy_time calculation errors.
>>>>
>>>> Doesn't return effective_cpu_util() either scale or min(scale, util)
>>>> with scale = arch_scale_cpu_capacity(cpu)? So the util sum over the PD
>>>> cannot exceed eenv->cpu_cap?
>>>
>>> In effective_cpu_util, the scale = arch_scale_cpu_capacity(cpu);
>>> Although there is the clamp of eenv->pd_cap, but let us consider the
>>> following simple scenario:
>>> The pd cpus are 4-7, and the arch_scale_capacity is 1024, and because
>>> of cpufreq-limit,
>>
>> Ah, this is due to:
>>
>> find_energy_efficient_cpu()
>>
>> ...
>> for (; pd; pd = pd->next)
>> ...
>> cpu_actual_cap = get_actual_cpu_capacity(cpu)
>>
>> for_each_cpu(cpu, cpus)
>> ...
>> eenv.pd_cap += cpu_actual_cap
>>
>> and:
>>
>> get_actual_cpu_capacity()
>>
>> ...
>> capacity = arch_scale_cpu_capacity(cpu)
>>
>> capacity -= max(hw_load_avg(cpu_rq(cpu)), cpufreq_get_pressure(cpu))
>>
>> which got introduced by f1f8d0a22422 ("sched/cpufreq: Take cpufreq
>> feedback into account").
>
> I don't think it was introduced by f1f8d0a22422, because f1f8d0a22422
> just replaced the cpu_thermal_cap with get_actual_cpu_capacity(cpu).
> The eenv.cpu_cap was introduced by 3e8c6c9aac42 ("sched/fair: Remove
> task_util from effective utilization in feec()").
Yes, you're right. 3e8c6c9aac42 changed it from per-CPU to per-PD
capping.
In case we want to go back to per-CPU then we should remove the
eenv->pd_cap capping in eenv_pd_busy_time().
-->8--
@@ -7864,16 +7864,15 @@ static inline void eenv_pd_busy_time(struct energy_env *eenv,
struct cpumask *pd_cpus,
struct task_struct *p)
{
- unsigned long busy_time = 0;
int cpu;
for_each_cpu(cpu, pd_cpus) {
unsigned long util = cpu_util(cpu, p, -1, 0);
- busy_time += effective_cpu_util(cpu, util, NULL, NULL);
+ util = effective_cpu_util(cpu, util, NULL, NULL);
+ util = min(util, eenv->cpu_cap);
+ eenv->pd_busy_time += util;
}
-
- eenv->pd_busy_time = min(eenv->pd_cap, busy_time);
}
I'm wondering whether we would need the:
if (dst_cpu >= 0)
busy_time = min(eenv->pd_cap, busy_time + eenv->task_busy_time);
in compute_energy() anymore since we only get a candidate CPU in feec()
after checking with util_fits_cpu() if cpu can accommodate p :
feec()
...
for_each_cpu()
util = cpu_util(cpu, p, cpu, ...)
cpu_cap = capacity_of()
...
fits = util_fits_cpu(util, ..., cpu);
if (!fits)
continue
/* check if candidate CPU */
next prev parent reply other threads:[~2024-06-21 10:22 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 7:06 Xuewen Yan
2024-06-07 7:19 ` Dietmar Eggemann
2024-06-07 8:20 ` Xuewen Yan
2024-06-07 10:30 ` Dietmar Eggemann
2024-06-07 10:37 ` Xuewen Yan
2024-06-21 10:22 ` Dietmar Eggemann [this message]
2024-06-24 2:27 ` Xuewen Yan
2024-06-09 22:55 ` Qais Yousef
2024-06-12 8:11 ` Xuewen Yan
2024-06-16 22:20 ` Qais Yousef
2024-06-17 7:27 ` Xuewen Yan
2024-06-17 11:03 ` Qais Yousef
2024-06-18 14:58 ` Qais Yousef
2024-06-19 2:46 ` Xuewen Yan
2024-06-19 18:03 ` Qais Yousef
2024-06-20 3:08 ` Xuewen Yan
2024-06-21 10:40 ` Dietmar Eggemann
2024-06-21 13:00 ` Vincent Guittot
2024-06-24 2:35 ` Xuewen Yan
2024-06-18 15:20 ` Vincent Guittot
2024-06-18 15:26 ` Qais Yousef
2024-06-17 9:07 ` Vincent Guittot
2024-06-17 10:53 ` Qais Yousef
2024-06-18 15:23 ` Vincent Guittot
2024-06-18 15:39 ` Qais Yousef
2024-06-18 21:05 ` Vincent Guittot
2024-06-19 18:01 ` Qais Yousef
2024-06-19 3:05 ` Xuewen Yan
2024-06-19 18:10 ` Qais Yousef
2024-06-20 7:45 ` Vincent Guittot
2024-06-20 11:37 ` Qais Yousef
2024-06-21 8:22 ` Dietmar Eggemann
2024-06-11 9:08 ` Christian Loehle
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=e2fdb89d-7594-4025-8e20-299dddc80497@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=juri.lelli@redhat.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=vincent.donnefort@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xuewen.yan94@gmail.com \
--cc=xuewen.yan@unisoc.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
all inboxes | Powered by JetHome®