On 10/11/2021 06:36, Xuewen Yan wrote: > Hi Dietmar > On Tue, Nov 9, 2021 at 5:43 PM Dietmar Eggemann > <dietmar.eggemann@xxxxxxx> wrote: >> >> On 08/11/2021 09:49, Xuewen Yan wrote: >>> Hi Dietmar >>> >>> On Sat, Nov 6, 2021 at 1:20 AM Dietmar Eggemann >>> <dietmar.eggemann@xxxxxxx> wrote: >>>> >>>> On 05/11/2021 06:58, Zhaoyang Huang wrote: [...] >>>> Even the CFS part (cpu_rq(CPUx)->cfs.avg.util_avg) can be larger than >>>> the original cpu capacity (rq->cpu_capacity_orig). >>>> >>>> Have a look at cpu_util(). capacity_orig_of(CPUx) and >>>> arch_scale_cpu_capacity(CPUx) both returning rq->cpu_capacity_orig. >>>> >>> >>> Well, your means is we should not use the 1024 and should use the >>> original cpu capacity? >>> And maybe use the "sched_cpu_util()" is a good choice just like this: >>> >>> + if (current->in_memstall) >>> + growth_fixed = div64_ul(cpu_util_cfs(rq) * growth, >>> sched_cpu_util(rq->cpu, capacity_orig_of(rq->cpu))); >> >> Not sure about this. In case util_cfs=0 you would get scale=0. > > Yes , we should consider it. In addition, it also should be considered > when util_cfs > capacity_orig because of the UTIL_EST...... We should ]-clamp cpu_util_cfs() with capacity_orig_of(), like we currently do for the CFS internal cpu_util(). In fact, we should only use one function for this. Sent a patch out: https://lkml.kernel.org/r/20211112141349.155713-1-dietmar.eggemann@xxxxxxx%3E [...]
