All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Juri Lelli <juri.lelli@redhat.com>,
	peterz@infradead.org, mingo@redhat.com
Cc: Patrick Bellasi <patrick.bellasi@arm.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel/sched/topology: Clarify root domain(s) debug string
Date: Fri, 25 May 2018 13:35:33 +0200	[thread overview]
Message-ID: <ba17ff9c-d687-2099-eec5-211fd195efd0@arm.com> (raw)
In-Reply-To: <20180524152936.17611-1-juri.lelli@redhat.com>

On 05/24/2018 05:29 PM, 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
> 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>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
> Cc: Patrick Bellasi <patrick.bellasi@arm.com>
> Cc: linux-kernel@vger.kernel.org
> ---
>   kernel/sched/topology.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 64cc564f5255..61a1125c1ae4 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -1708,7 +1708,7 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
>   	rcu_read_unlock();
>   
>   	if (rq && sched_debug_enabled) {
> -		pr_info("span: %*pbl (max cpu_capacity = %lu)\n",
> +		pr_info("root domain span: %*pbl (max cpu_capacity = %lu)\n",
>   			cpumask_pr_args(cpu_map), rq->rd->max_cpu_capacity);
>   	}
>   
> 

Looks good to me. Probably especially helpful when setting up exclusive 
cpusets.

Juno with big and little exclusive cpuset:

...
[  124.231333] CPU1 attaching sched-domain(s):
[  124.235482]  domain-0: span=1-2 level=MC
[  124.239382]   groups: 1:{ span=1 }, 2:{ span=2 }
[  124.243969] CPU2 attaching sched-domain(s):
[  124.248112]  domain-0: span=1-2 level=MC
[  124.251998]   groups: 2:{ span=2 }, 1:{ span=1 }
[  124.256585] root domain span: 1-2 (max cpu_capacity = 1024)
[  124.262150] CPU0 attaching sched-domain(s):
[  124.266307]  domain-0: span=0,3-5 level=MC
[  124.270366]   groups: 0:{ span=0 cap=446 }, 3:{ span=3 cap=446 }, 4:{ 
span=4 cap=446 }, 5:{ span=5 cap=446 }
[  124.280131] CPU3 attaching sched-domain(s):
[  124.284273]  domain-0: span=0,3-5 level=MC
[  124.288334]   groups: 3:{ span=3 cap=446 }, 4:{ span=4 cap=446 }, 5:{ 
span=5 cap=446 }, 0:{ span=0 cap=446 }
[  124.298096] CPU4 attaching sched-domain(s):
[  124.302239]  domain-0: span=0,3-5 level=MC
[  124.306298]   groups: 4:{ span=4 cap=446 }, 5:{ span=5 cap=446 }, 0:{ 
span=0 cap=446 }, 3:{ span=3 cap=446 }
[  124.316063] CPU5 attaching sched-domain(s):
[  124.320205]  domain-0: span=0,3-5 level=MC
[  124.324265]   groups: 5:{ span=5 cap=446 }, 0:{ span=0 cap=446 }, 3:{ 
span=3 cap=446 }, 4:{ span=4 cap=446 }
[  124.334031] root domain span: 0,3-5 (max cpu_capacity = 446)

  parent reply	other threads:[~2018-05-25 11:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-24 15:29 [PATCH] kernel/sched/topology: Clarify root domain(s) debug string Juri Lelli
2018-05-25  9:46 ` [tip:sched/core] sched/topology: " tip-bot for Juri Lelli
2018-05-25 11:35 ` Dietmar Eggemann [this message]
2018-05-25 11:52   ` [PATCH] kernel/sched/topology: " Juri Lelli
2018-05-28  1:04 ` Joel Fernandes

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=ba17ff9c-d687-2099-eec5-211fd195efd0@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.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 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.