From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Mel Gorman <mgorman@techsingularity.net>,
Rik van Riel <riel@surriel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [PATCH] sched/fair: Optimize select_idle_core
Date: Fri, 6 Dec 2019 18:23:17 +0530 [thread overview]
Message-ID: <20191206125317.GC22330@linux.vnet.ibm.com> (raw)
In-Reply-To: <6242deaa-e570-3384-0737-e49abb0599dd@arm.com>
Hi Valentin,
> Say you have a 4-core SMT2 system with the usual numbering scheme:
>
> {0, 4} {1, 5} {2, 6} {3, 7}
> CORE0 CORE1 CORE2 CORE3
>
>
> Say 'target' is the prev_cpu, in that case let's pick 5. Because we do a
> for_each_cpu_wrap(), our iteration for 'core' would start with
>
> 5, 6, 7, ...
>
> So say CORE2 is entirely idle and CORE1 isn't, we would go through the
> inner loop on CORE1 (with 'core' == 5), then go through CORE2 (with
> 'core' == 6) and return 'core'. I find it a bit unusual that we wouldn't
> return the first CPU in the SMT mask, usually we try to fill sched_groups
> in cpumask order.
>
>
> If we could have 'cpus' start with only primary CPUs, that would simplify
> things methinks:
>
Its probably something to think over. I probably don't have an answer on why
we are not choosing the starting cpu to be primary CPU. Would we have to
think of the case where the Primary CPUs are online / offline etc? I mean
with target cpu, we know the CPU is online for sure.
> for_each_cpu_wrap(core, cpus, target) {
> bool idle = true;
>
> for_each_cpu(cpu, cpu_smt_mask(core)) {
> if (!available_idle_cpu(cpu)) {
> idle = false;
> break;
> }
>
> __cpumask_clear_cpu(core, cpus);
>
> if (idle)
> return core;
>
>
> Food for thought; your change itself looks fine as it is.
>
> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
>
Thanks for the review.
--
Thanks and Regards
Srikar Dronamraju
next prev parent reply other threads:[~2019-12-06 12:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 17:23 [PATCH] sched/fair: Optimize select_idle_core Srikar Dronamraju
2019-12-05 17:27 ` Vincent Guittot
2019-12-05 17:51 ` Srikar Dronamraju
2019-12-05 18:52 ` Vincent Guittot
2019-12-06 8:16 ` Srikar Dronamraju
2019-12-06 13:27 ` Vincent Guittot
2019-12-06 13:39 ` Srikar Dronamraju
2019-12-06 16:48 ` Vincent Guittot
2019-12-06 12:00 ` Valentin Schneider
2019-12-06 12:32 ` Peter Zijlstra
2019-12-06 12:53 ` Srikar Dronamraju [this message]
2019-12-06 16:57 ` 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=20191206125317.GC22330@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
--cc=valentin.schneider@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox