linux-kernel - Re: [PATCH RFC v2] sched/fair: simplify the work when reweighting entity

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <9149cf7c-df81-cf9d-65f7-a51d4ec76f78@arm.com>
Date:   Tue, 11 Aug 2020 11:50:12 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Jiang Biao <benbjiang@...il.com>, mingo@...hat.com,
        peterz@...radead.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org
Cc:     rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        linux-kernel@...r.kernel.org, Jiang Biao <benbjiang@...cent.com>
Subject: Re: [PATCH RFC v2] sched/fair: simplify the work when reweighting
 entity

On 06/08/2020 18:14, Jiang Biao wrote:
> From: Jiang Biao <benbjiang@...cent.com>
> 
> If a se is on_rq when reweighting entity, all we need should be
> updating the load of cfs_rq, other dequeue/enqueue work could be
> redundant, such as,
> * nr_running--/nr_running++
> 
> Even though the following dequeue/enqueue path would never be reached
> * account_numa_dequeue/account_numa_enqueue
> * list_del/list_add from/into cfs_tasks
> but it could be a little confusing.
> 
> Simplifying the logic could be helpful to reduce a litte overhead for
> hot path, and make it cleaner and more readable.

LGTM. I guess you have to resend it w/o the RFC tag.

Maybe you can rework the patch header a little?

Something like this:

The code in reweight_entity() can be simplified.

For a sched entity on the rq, the entity accounting can be replaced by
cfs_rq instantaneous load updates currently called from within the
entity accounting.

Even though an entity on the rq can't represent a task in
reweight_entity() (a task is always dequeued before calling this
function) and so the numa task accounting and the rq->cfs_tasks list
management of the entity accounting are never called, the redundant
cfs_rq->nr_running decrement/increment will be avoided.

> 
> Signed-off-by: Jiang Biao <benbjiang@...cent.com>
> ---
> v2<-v1: 
> - Amend the commit log.
> 
>  kernel/sched/fair.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 04fa8dbcfa4d..18a8fc7bd0de 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3086,7 +3086,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  		/* commit outstanding execution time */
>  		if (cfs_rq->curr == se)
>  			update_curr(cfs_rq);
> -		account_entity_dequeue(cfs_rq, se);
> +		update_load_sub(&cfs_rq->load, se->load.weight);
>  	}
>  	dequeue_load_avg(cfs_rq, se);
>  
> @@ -3102,7 +3102,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  
>  	enqueue_load_avg(cfs_rq, se);
>  	if (se->on_rq)
> -		account_entity_enqueue(cfs_rq, se);
> +		update_load_add(&cfs_rq->load, se->load.weight);
>  
>  }