All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Peng Liu <iwtbavbm@gmail.com>, linux-kernel@vger.kernel.org
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	qais.yousef@arm.com, morten.rasmussen@arm.com
Subject: Re: [PATCH] sched/fair: fix sgc->{min,max}_capacity miscalculate
Date: Fri, 3 Jan 2020 14:44:00 +0000	[thread overview]
Message-ID: <7370a631-1e9a-90ba-dcbe-f714ecb0fb26@arm.com> (raw)
In-Reply-To: <20200103142152.GA4551@iZj6chx1xj0e0buvshuecpZ>

On 03/01/2020 14:21, Peng Liu wrote:
> Thanks for your patient explanation, and the picture is intuitive
> and clear. Indeed, the group in lowest domain only contains one CPU, and
> the only CPU in the first group should be the rq's CPU. So, I wonder if
> we can do like this?
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 2d170b5da0e3..c9d7613c74d2 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7793,9 +7793,6 @@ void update_group_capacity(struct sched_domain *sd, int cpu)
>                  */
> 
>                 for_each_cpu(cpu, sched_group_span(sdg)) {
> -                       struct sched_group_capacity *sgc;
> -                       struct rq *rq = cpu_rq(cpu);
> -
>                         /*
>                          * build_sched_domains() -> init_sched_groups_capacity()
>                          * gets here before we've attached the domains to the
> @@ -7807,15 +7804,11 @@ void update_group_capacity(struct sched_domain *sd, int cpu)
>                          * This avoids capacity from being 0 and
>                          * causing divide-by-zero issues on boot.
>                          */
> -                       if (unlikely(!rq->sd)) {
> -                               capacity += capacity_of(cpu);
> -                       } else {
> -                               sgc = rq->sd->groups->sgc;
> -                               capacity += sgc->capacity;
> -                       }
> +                       unsigned long cpu_cap = capacity_of(cpu);
> 
> -                       min_capacity = min(capacity, min_capacity);
> -                       max_capacity = max(capacity, max_capacity);
> +                       min_capacity = min(cpu_cap, min_capacity);
> +                       max_capacity = max(cpu_cap, max_capacity);
> +                       capacity += cpu_cap;
>                 }
>         } else  {
>                 /*
> 

Yep, if we refactor it to always use capacity_of() we'd end up with
something like this. The comment block could be updated (or removed) as
well.

There must be (or have been) a reason to use the sched_group_capacity
structure, but I'm not aware of it and I don't have time right now to dig
through the git history to figure it out. I didn't see anyone suggesting
or talking about this simplification in the discussion thread of

  9abf24d46518 ("sched: Check sched_domain before computing group power")

What you can try is sending that as the v2, and see if anyone screams. FWIW
you can add this to it too:

Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>

      reply	other threads:[~2020-01-03 14:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31  3:51 [PATCH] sched/fair: fix sgc->{min,max}_capacity miscalculate Peng Liu
2020-01-01  5:56 ` Valentin Schneider
2020-01-01 14:13   ` Peng Liu
2020-01-01 18:55     ` Valentin Schneider
2020-01-03 14:21       ` Peng Liu
2020-01-03 14:44         ` Valentin Schneider [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7370a631-1e9a-90ba-dcbe-f714ecb0fb26@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=iwtbavbm@gmail.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.