| 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
| ||
|
Message-ID: <CAKfTPtBUec-OobXGpWMfxXuq2s==o5LquNWGEo5Te_2Gqw1SHw@mail.gmail.com>
Date: Fri, 4 Sep 2015 11:08:41 +0200
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Morten Rasmussen <morten.rasmussen@....com>
Cc: Peter Zijlstra <peterz@...radead.org>,
"mingo@...hat.com" <mingo@...hat.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Dietmar Eggemann <Dietmar.Eggemann@....com>,
Yuyang Du <yuyang.du@...el.com>,
Michael Turquette <mturquette@...libre.com>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
Juri Lelli <Juri.Lelli@....com>,
Sai Charan Gurrappadi <sgurrappadi@...dia.com>,
pang.xunlei@....com.cn, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/6] sched/fair: Name utilization related data and
functions consistently
On 14 August 2015 at 18:23, Morten Rasmussen <morten.rasmussen@....com> wrote:
> From: Dietmar Eggemann <dietmar.eggemann@....com>
>
> 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 <dietmar.eggemann@....com>
> Signed-off-by: Morten Rasmussen <morten.rasmussen@....com>
> ---
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists