From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758635AbbIDJJH (ORCPT ); Fri, 4 Sep 2015 05:09:07 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:35991 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757273AbbIDJJD (ORCPT ); Fri, 4 Sep 2015 05:09:03 -0400 MIME-Version: 1.0 In-Reply-To: <1439569394-11974-5-git-send-email-morten.rasmussen@arm.com> References: <1439569394-11974-1-git-send-email-morten.rasmussen@arm.com> <1439569394-11974-5-git-send-email-morten.rasmussen@arm.com> From: Vincent Guittot Date: Fri, 4 Sep 2015 11:08:41 +0200 Message-ID: Subject: Re: [PATCH 4/6] sched/fair: Name utilization related data and functions consistently To: Morten Rasmussen Cc: Peter Zijlstra , "mingo@redhat.com" , Daniel Lezcano , Dietmar Eggemann , Yuyang Du , Michael Turquette , "rjw@rjwysocki.net" , Juri Lelli , Sai Charan Gurrappadi , pang.xunlei@zte.com.cn, linux-kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14 August 2015 at 18:23, Morten Rasmussen wrote: > From: Dietmar Eggemann > > Use the advent of the per-entity load tracking rewrite to streamline the > naming of utilization related data and functions by using > {prefix_}util{_suffix} consistently. Moreover call both signals > ({se,cfs}.avg.util_avg) utilization. I don't have a strong opinion about the naming of this variable but I remember a discussion about this topic: https://lkml.org/lkml/2014/9/11/474 : "Call the pure running number 'utilization' and this scaled with capacity 'usage' " The utilization has been shorten to util with the rewrite of the pelt, so the current use of usage in get_cpu_usage still follows this rule. So why do you want to change that now ? Furthermore, cfs.avg.util_avg is a load whereas sgs->group_util is a capacity. Both don't use the same unit and same range which can be confusing when you read the code Regards, Vincent > > Signed-off-by: Dietmar Eggemann > Signed-off-by: Morten Rasmussen > --- > kernel/sched/fair.c | 37 +++++++++++++++++++------------------ > 1 file changed, 19 insertions(+), 18 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 63be5a5..4cc3050 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4825,31 +4825,32 @@ static int select_idle_sibling(struct task_struct *p, int target) > return target; > } > /* > - * get_cpu_usage returns the amount of capacity of a CPU that is used by CFS > + * cpu_util returns the amount of capacity of a CPU that is used by CFS > * tasks. The unit of the return value must be the one of capacity so we can > - * compare the usage with the capacity of the CPU that is available for CFS > - * task (ie cpu_capacity). > + * compare the utilization with the capacity of the CPU that is available for > + * CFS task (ie cpu_capacity). > * cfs.avg.util_avg is the sum of running time of runnable tasks on a > * CPU. It represents the amount of utilization of a CPU in the range > - * [0..SCHED_LOAD_SCALE]. The usage of a CPU can't be higher than the full > - * capacity of the CPU because it's about the running time on this CPU. > + * [0..SCHED_LOAD_SCALE]. The utilization of a CPU can't be higher than the > + * full capacity of the CPU because it's about the running time on this CPU. > * Nevertheless, cfs.avg.util_avg can be higher than SCHED_LOAD_SCALE > * because of unfortunate rounding in util_avg or just > * after migrating tasks until the average stabilizes with the new running > - * time. So we need to check that the usage stays into the range > + * time. So we need to check that the utilization stays into the range > * [0..cpu_capacity_orig] and cap if necessary. > - * Without capping the usage, a group could be seen as overloaded (CPU0 usage > - * at 121% + CPU1 usage at 80%) whereas CPU1 has 20% of available capacity > + * Without capping the utilization, a group could be seen as overloaded (CPU0 > + * utilization at 121% + CPU1 utilization at 80%) whereas CPU1 has 20% of > + * available capacity. > */ > -static int get_cpu_usage(int cpu) > +static int cpu_util(int cpu) > { > - unsigned long usage = cpu_rq(cpu)->cfs.avg.util_avg; > + unsigned long util = cpu_rq(cpu)->cfs.avg.util_avg; > unsigned long capacity = capacity_orig_of(cpu); > > - if (usage >= SCHED_LOAD_SCALE) > + if (util >= SCHED_LOAD_SCALE) > return capacity; > > - return (usage * capacity) >> SCHED_LOAD_SHIFT; > + return (util * capacity) >> SCHED_LOAD_SHIFT; > } > > /* > @@ -5941,7 +5942,7 @@ struct sg_lb_stats { > unsigned long sum_weighted_load; /* Weighted load of group's tasks */ > unsigned long load_per_task; > unsigned long group_capacity; > - unsigned long group_usage; /* Total usage of the group */ > + unsigned long group_util; /* Total utilization of the group */ > unsigned int sum_nr_running; /* Nr tasks running in the group */ > unsigned int idle_cpus; > unsigned int group_weight; > @@ -6174,8 +6175,8 @@ static inline int sg_imbalanced(struct sched_group *group) > * group_has_capacity returns true if the group has spare capacity that could > * be used by some tasks. > * We consider that a group has spare capacity if the * number of task is > - * smaller than the number of CPUs or if the usage is lower than the available > - * capacity for CFS tasks. > + * smaller than the number of CPUs or if the utilization is lower than the > + * available capacity for CFS tasks. > * For the latter, we use a threshold to stabilize the state, to take into > * account the variance of the tasks' load and to return true if the available > * capacity in meaningful for the load balancer. > @@ -6189,7 +6190,7 @@ group_has_capacity(struct lb_env *env, struct sg_lb_stats *sgs) > return true; > > if ((sgs->group_capacity * 100) > > - (sgs->group_usage * env->sd->imbalance_pct)) > + (sgs->group_util * env->sd->imbalance_pct)) > return true; > > return false; > @@ -6210,7 +6211,7 @@ group_is_overloaded(struct lb_env *env, struct sg_lb_stats *sgs) > return false; > > if ((sgs->group_capacity * 100) < > - (sgs->group_usage * env->sd->imbalance_pct)) > + (sgs->group_util * env->sd->imbalance_pct)) > return true; > > return false; > @@ -6258,7 +6259,7 @@ static inline void update_sg_lb_stats(struct lb_env *env, > load = source_load(i, load_idx); > > sgs->group_load += load; > - sgs->group_usage += get_cpu_usage(i); > + sgs->group_util += cpu_util(i); > sgs->sum_nr_running += rq->cfs.h_nr_running; > > if (rq->nr_running > 1) > -- > 1.9.1 >