linux-kernel - Re: [PATCH v4 2/3] sched/uclamp: Ignore (util == 0) optimization in feec() when p_util

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <77cd2ad7-7b94-7c45-fec3-131452229fc1@arm.com>
Date:   Wed, 23 Aug 2023 12:30:17 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Qais Yousef <qyousef@...alina.io>, Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Vincent Guittot <vincent.guittot@...aro.org>
Cc:     linux-kernel@...r.kernel.org, Lukasz Luba <lukasz.luba@....com>,
        Wei Wang <wvw@...gle.com>, Xuewen Yan <xuewen.yan94@...il.com>,
        Hank <han.lin@...iatek.com>,
        Jonathan JMChen <Jonathan.JMChen@...iatek.com>,
        Hongyan Xia <hongyan.xia2@....com>
Subject: Re: [PATCH v4 2/3] sched/uclamp: Ignore (util == 0) optimization in
 feec() when p_util_max = 0

On 22/08/2023 00:45, Qais Yousef wrote:
> find_energy_efficient_cpu() bails out early if effective util of the
> task is 0 as the delta at this point will be zero and there's nothing
> for EAS to do. When uclamp is being used, this could lead to wrong
> decisions when uclamp_max is set to 0. In this case the task is capped

Does uclamp_max plays a role here? We check util and uclamp_min in this
condition.

> to performance point 0, but it is actually running and consuming energy
> and we can benefit from EAS energy calculations.
> 
> Rework the condition so that it bails out for when util is actually 0 or
> uclamp_min is requesting a higher performance point.

I do get the condition:

> +	if (!task_util_est(p) && p_util_min == 0)
>  		goto unlock;

which is !(task_util_est(p) || p_util_min)

But the text then should be '... bails out for when util is actually 0
and uclamp_min is 0 too'? Or 'uclamp_min is not requesting ...'.

> We can do that without needing to use uclamp_task_util(); remove it.
> 
> Fixes: d81304bc6193 ("sched/uclamp: Cater for uclamp in find_energy_efficient_cpu()'s early exit condition")
> Reviewed-by: Vincent Guittot <vincent.guittot@...aro.org>
> Signed-off-by: Qais Yousef (Google) <qyousef@...alina.io>
> ---
>  kernel/sched/fair.c | 18 +-----------------
>  1 file changed, 1 insertion(+), 17 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 5da6538ed220..e19a36e7b433 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4571,22 +4571,6 @@ static inline unsigned long task_util_est(struct task_struct *p)
>  	return max(task_util(p), _task_util_est(p));
>  }
>  
> -#ifdef CONFIG_UCLAMP_TASK
> -static inline unsigned long uclamp_task_util(struct task_struct *p,
> -					     unsigned long uclamp_min,
> -					     unsigned long uclamp_max)
> -{
> -	return clamp(task_util_est(p), uclamp_min, uclamp_max);
> -}
> -#else
> -static inline unsigned long uclamp_task_util(struct task_struct *p,
> -					     unsigned long uclamp_min,
> -					     unsigned long uclamp_max)
> -{
> -	return task_util_est(p);
> -}
> -#endif
> -
>  static inline void util_est_enqueue(struct cfs_rq *cfs_rq,
>  				    struct task_struct *p)
>  {
> @@ -7699,7 +7683,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>  	target = prev_cpu;
>  
>  	sync_entity_load_avg(&p->se);
> -	if (!uclamp_task_util(p, p_util_min, p_util_max))
> +	if (!task_util_est(p) && p_util_min == 0)
>  		goto unlock;
>  
>  	eenv_task_busy_time(&eenv, p, prev_cpu);

With the question about the content of the patch header in mind:

Reviewed-by: Dietmar Eggemann <dietmar.eggemann@....com>