linux-kernel - Re: [RFC][PATCH 14/10] sched, fair: Fix the group

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] [day] [month] [year] [list]

Date:	Wed, 4 Sep 2013 09:44:17 +0200
From:	Vincent Guittot <vincent.guittot@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>, Paul Turner <pjt@...gle.com>,
	Alex Shi <alex.shi@...el.com>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Morten Rasmussen <morten.rasmussen@....com>,
	Namhyung Kim <namhyung@...nel.org>,
	Lei Wen <leiwen@...vell.com>, Joonsoo Kim <js1304@...il.com>,
	Rik van Riel <riel@...riel.com>
Subject: Re: [RFC][PATCH 14/10] sched, fair: Fix the group_capacity computation

On 28 August 2013 13:16, Peter Zijlstra <peterz@...radead.org> wrote:
>
> Subject: sched, fair: Fix the group_capacity computation
> From: Peter Zijlstra <peterz@...radead.org>
> Date: Wed Aug 28 12:40:38 CEST 2013
>
> Do away with 'phantom' cores due to N*frac(smt_power) >= 1 by limiting
> the capacity to the actual number of cores.
>

Peter,

your patch also solves the 'phantom' big cores that can appear on HMP
system because big cores have a cpu_power >=  SCHED_POWER_SCALE in
order to express a higher capacity than LITTLE cores.

Acked-by Vincent Guittot <vincent.guitto@...aro.org>

Vincent

> The assumption of 1 < smt_power < 2 is an actual requirement because
> of what SMT is so this should work regardless of the SMT
> implementation.
>
> It can still be defeated by creative use of cpu hotplug, but if you're
> one of those freaks, you get to live with it.
>
> Signed-off-by: Peter Zijlstra <peterz@...radead.org>
> ---
>  kernel/sched/fair.c |   20 +++++++++++++-------
>  1 file changed, 13 insertions(+), 7 deletions(-)
>
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4554,18 +4554,24 @@ static inline int sg_imbalanced(struct s
>  /*
>   * Compute the group capacity.
>   *
> - * For now the capacity is simply the number of power units in the group_power.
> - * A power unit represents a full core.
> - *
> - * This has an issue where N*frac(smt_power) >= 1, in that case we'll see extra
> - * 'cores' that aren't actually there.
> + * Avoid the issue where N*frac(smt_power) >= 1 creates 'phantom' cores by
> + * first dividing out the smt factor and computing the actual number of cores
> + * and limit power unit capacity with that.
>   */
>  static inline int sg_capacity(struct lb_env *env, struct sched_group *group)
>  {
> +       unsigned int capacity, smt, cpus;
> +       unsigned int power, power_orig;
> +
> +       power = group->sgp->power;
> +       power_orig = group->sgp->power_orig;
> +       cpus = group->group_weight;
>
> -       unsigned int power = group->sgp->power;
> -       unsigned int capacity = DIV_ROUND_CLOSEST(power, SCHED_POWER_SCALE);
> +       /* smt := ceil(cpus / power), assumes: 1 < smt_power < 2 */
> +       smt = DIV_ROUND_UP(SCHED_POWER_SCALE * cpus, power_orig);
> +       capacity = cpus / smt; /* cores */
>
> +       capacity = min_t(capacity, DIV_ROUND_CLOSEST(power, SCHED_POWER_SCALE));
>         if (!capacity)
>                 capacity = fix_small_capacity(env->sd, group);
>
--
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/