All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: linux-kernel@vger.kernel.org
Cc: peterz@infradead.org, mingo@kernel.org,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	morten.rasmussen@arm.com, mgorman@techsingularity.net
Subject: Re: [PATCH] sched/topology: Fix overlapping sched_group build
Date: Wed, 25 Mar 2020 18:09:44 +0000	[thread overview]
Message-ID: <jhjbloki9w7.mognet@arm.com> (raw)
In-Reply-To: <jhjeetgiamv.mognet@arm.com>


On Wed, Mar 25 2020, Valentin Schneider wrote:
> On Tue, Mar 24 2020, Valentin Schneider wrote:
>>  kernel/sched/topology.c | 23 ++++++++++++++++++++---
>>  1 file changed, 20 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
>> index 8344757bba6e..7033b27e5162 100644
>> --- a/kernel/sched/topology.c
>> +++ b/kernel/sched/topology.c
>> @@ -866,7 +866,7 @@ build_balance_mask(struct sched_domain *sd, struct sched_group *sg, struct cpuma
>>                       continue;
>>
>>               /* If we would not end up here, we can't continue from here */
>> -		if (!cpumask_equal(sg_span, sched_domain_span(sibling->child)))
>> +		if (!cpumask_subset(sg_span, sched_domain_span(sibling->child)))
>
> So this is one source of issues; what I've done here is a bit stupid
> since we include CPUs that *cannot* end up there. What I should've done
> is something like:
>
>   cpumask_and(tmp, sched_domain_span(sibling->child), sched_domain_span(sd));
>   if (!cpumask_equal(sg_span, tmp))
>       ...
>
> But even with that I just unfold even more horrors: this breaks the
> overlapping sched_group_capacity (see 1676330ecfa8 ("sched/topology: Fix
> overlapping sched_group_capacity")).
>
> For instance, here I would have
>
>   CPU0-domain2-group4: span=4-5
>   CPU4-domain2-group4: span=4-7 mask=4-5
>

^ That's using Dietmar's qemu setup; on the D06 that is

  CPU0-domain2-group48: span=48-71
  CPU48-domain2-group48: span=48-95 mask=48-71

> Both groups are at the same topology level and have the same first CPU,
> so they point to the same sched_group_capacity structure - but they
> don't have the same span. They would without my "fix", but then the
> group spans are back to being wrong. I'm starting to think this is
> doomed, at least in the current state of things :/

  reply	other threads:[~2020-03-25 18:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 12:55 [PATCH] sched/topology: Fix overlapping sched_group build Valentin Schneider
2020-03-24 17:20 ` Valentin Schneider
2020-03-25 11:05   ` Dietmar Eggemann
2020-03-25 11:22     ` Valentin Schneider
2020-03-25 17:53 ` Valentin Schneider
2020-03-25 18:09   ` Valentin Schneider [this message]
2020-03-25 18:38     ` Valentin Schneider

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=jhjbloki9w7.mognet@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.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.