From: Joel Fernandes <joel@joelfernandes.org>
To: Juri Lelli <juri.lelli@redhat.com>
Cc: peterz@infradead.org, mingo@redhat.com,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Patrick Bellasi <patrick.bellasi@arm.com>,
linux-kernel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH] kernel/sched/topology: Clarify root domain(s) debug string
Date: Sun, 27 May 2018 18:04:25 -0700 [thread overview]
Message-ID: <20180528010425.GA64067@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20180524152936.17611-1-juri.lelli@redhat.com>
On Thu, May 24, 2018 at 05:29:36PM +0200, Juri Lelli wrote:
> When scheduler debug is enabled, building scheduling domains outputs
> information about how the domains are laid out and to which root domain
> each CPU (or sets of CPUs) belongs, e.g.:
>
> CPU0 attaching sched-domain(s):
> domain-0: span=0-5 level=MC
> groups: 0:{ span=0 }, 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 }
> CPU1 attaching sched-domain(s):
> domain-0: span=0-5 level=MC
> groups: 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 }, 0:{ span=0 }
>
> [...]
>
> span: 0-5 (max cpu_capacity = 1024)
>
> The fact that latest line refers to CPUs 0-5 root domain doesn't however look
last line?
> immediately obvious to me: one might wonder why span 0-5 is reported "again".
>
> Make it more clear by adding "root domain" to it, as to end with the
> following.
>
> CPU0 attaching sched-domain(s):
> domain-0: span=0-5 level=MC
> groups: 0:{ span=0 }, 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 }
> CPU1 attaching sched-domain(s):
> domain-0: span=0-5 level=MC
> groups: 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 }, 0:{ span=0 }
>
> [...]
>
> root domain span: 0-5 (max cpu_capacity = 1024)
>
> Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
I played the sched_load_balance flag to trigger this and it makes sense to
improve the print with 'root domain'.
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
One thing I believe is a bit weird is sched_load_balance also can affect the
wake-up path, because a NULL sd is attached to the rq if sched_load_balance
is set to 0.
This could turn off the "for_each_domain(cpu, tmp)" loop in
select_task_rq_fair and hence we would always end up in the
select_idle_sibling path for those CPUs.
It also means that "XXX always" can/should be removed because sd can very
well be NULL for other sd_flag types as well, not just sd_flag ==
SD_BALANCE_WAKE. I'll send a patch to remove that comment as I just tested
this is true.
thanks,
- Joel
prev parent reply other threads:[~2018-05-28 1:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-24 15:29 Juri Lelli
2018-05-25 9:46 ` [tip:sched/core] sched/topology: " tip-bot for Juri Lelli
2018-05-25 11:35 ` [PATCH] kernel/sched/topology: " Dietmar Eggemann
2018-05-25 11:52 ` Juri Lelli
2018-05-28 1:04 ` Joel Fernandes [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=20180528010425.GA64067@joelaf.mtv.corp.google.com \
--to=joel@joelfernandes.org \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®