From: Valentin Schneider <valentin.schneider@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v3 9/9] sched/topology: Define and use shortcut pointers for wakeup sd_flag scan
Date: Thu, 16 Apr 2020 16:27:32 +0100 [thread overview]
Message-ID: <jhjv9lz78nv.mognet@arm.com> (raw)
In-Reply-To: <CAKfTPtD5x_NQ1KfHhTiAR3eNA85+k13nfSR-9_PKLp6FgVu08A@mail.gmail.com>
On 16/04/20 14:36, Vincent Guittot wrote:
>> Coming back to the v2 discussion on this patch
>>
>> https://lore.kernel.org/r/20200311181601.18314-10-valentin.schneider@arm.com
>>
>> SD_BALANCE_WAKE is not used in mainline anymore, so wakeups are always
>> fast today.
>>
>> I.e. you wouldn't need a per_cpu(sd_balance_wake, cpu) since it's always
>> NULL.
>>
>> I.e. want_affine logic and the 'for_each_domain(cpu, tmp)' isn't needed
>> anymore.
>>
>> This will dramatically simplify the code in select_task_rq_fair().
>>
>> But I guess Vincent wants to keep the functionality so we're able to
>> enable SD_BALANCE_WAKE on certain sd's?
>
> I looked too quickly what was done by this patch. I thought that it
> was adding a per_cpu pointer for all cases including the fast path
> with wake affine but it only skips the for_each_domain loop for the
> slow paths which don't need it because they are already slow.
>
> It would be better to keep the for_each_domain loop for slow paths and
> to use a per_cpu pointer for fast_path/wake affine. Regarding the
> wake_affine path, we don't really care about looping all domains and
> we could directly use the highest domain because wake_affine() that is
> used in the loop, only uses the imbalance_pct of the sched domain for
> wake_affine_weight() and it should not harm to use only the highest
> domain and then select_idle_sibling doesn't use it but the llc or
> asym_capacity pointer instead.
So Dietmar's pointing out that sd will always be NULL for want_affine,
because want_affine can only be true at wakeups and we don't have any
topologies with SD_BALANCE_WAKE anymore. We would still want to call
wake_affine() though, because that can change new_cpu.
What you are adding on top is that the only sd field used in wake_affine()
is the imbalance_pct, so we could take a shortcut and just go for the
highest domain with SD_WAKE_AFFINE; i.e. something like this:
---
if (want_affine) {
// We can cache that at topology buildup
sd = highest_flag_domain(cpu, SD_WAKE_AFFINE);
if (cpumask_test_cpu(prev_cpu, sched_domain_span(sd) &&
cpu != prev_cpu)
new_cpu = wake_affine();
// Directly go to select_idle_sibling()
goto sis;
}
// !want_affine logic here
---
As for the !want_affine part, we could either keep the current domain walk
(IIUC this is what you are suggesting) or go for the extra cached pointers
I'm introducing.
Now if we are a bit bolder than that, because there are no more
(mainline) topologies w/ SD_BALANCE_WAKE, we could even turn the above
into:
---
if (wake_flags & WF_TTWU) {
if (want_affine) {
// We can cache that at topology buildup
sd = highest_flag_domain(cpu, SD_WAKE_AFFINE);
if (cpumask_test_cpu(prev_cpu, sched_domain_span(sd) &&
cpu != prev_cpu)
new_cpu = wake_affine();
}
// Directly go to select_idle_sibling()
goto sis;
}
// !want_affine logic here
---
This in turns mean we could get rid of SD_BALANCE_WAKE entirely... I'm a
bit more reluctant to that only because the last SD_BALANCE_WAKE setter was
removed fairly recently, see
a526d466798d ("sched/topology: Remove SD_BALANCE_WAKE on asymmetric capacity systems")
next prev parent reply other threads:[~2020-04-16 15:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 21:05 [PATCH v3 0/9] sched: Streamline select_task_rq() & select_task_rq_fair() Valentin Schneider
2020-04-15 21:05 ` [PATCH v3 1/9] sched/fair: find_idlest_group(): Remove unused sd_flag parameter Valentin Schneider
2020-04-16 7:40 ` Vincent Guittot
2020-05-01 18:22 ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-04-15 21:05 ` [PATCH v3 2/9] sched/debug: Make sd->flags sysctl read-only Valentin Schneider
2020-05-01 18:22 ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-04-15 21:05 ` [PATCH v3 3/9] sched: Remove checks against SD_LOAD_BALANCE Valentin Schneider
2020-05-01 18:22 ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-04-15 21:05 ` [PATCH v3 4/9] sched/topology: Kill SD_LOAD_BALANCE Valentin Schneider
2020-05-01 18:22 ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-04-15 21:05 ` [PATCH v3 5/9] sched: Add WF_TTWU, WF_EXEC wakeup flags Valentin Schneider
2020-04-15 21:05 ` [PATCH v3 6/9] sched: Kill select_task_rq()'s sd_flag parameter Valentin Schneider
2020-04-16 7:42 ` Vincent Guittot
2020-04-16 10:24 ` Valentin Schneider
2020-04-16 10:47 ` Peter Zijlstra
2020-04-16 11:43 ` Valentin Schneider
2020-04-15 21:05 ` [PATCH v3 7/9] sched/fair: Dissociate wakeup decisions from SD flag value Valentin Schneider
2020-04-15 21:05 ` [PATCH v3 8/9] sched/fair: Split select_task_rq_fair want_affine logic Valentin Schneider
2020-04-15 21:05 ` [PATCH v3 9/9] sched/topology: Define and use shortcut pointers for wakeup sd_flag scan Valentin Schneider
2020-04-16 7:46 ` Vincent Guittot
2020-04-16 10:24 ` Valentin Schneider
2020-04-16 13:04 ` Dietmar Eggemann
2020-04-16 13:36 ` Vincent Guittot
2020-04-16 15:27 ` Valentin Schneider [this message]
2020-04-16 15:58 ` Vincent Guittot
2020-04-16 20:54 ` Valentin Schneider
2020-04-16 10:58 ` [PATCH v3 0/9] sched: Streamline select_task_rq() & select_task_rq_fair() Peter Zijlstra
2020-04-16 11:00 ` Peter Zijlstra
2020-04-16 11:02 ` Valentin Schneider
2020-04-16 13:00 ` Vincent Guittot
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=jhjv9lz78nv.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--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.