From: Quentin Perret <qperret@google.com>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
peterz@infradead.org, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, morten.rasmussen@arm.com
Subject: Re: [PATCH v3 2/7] sched/topology: Define and assign sched_domain flag metadata
Date: Thu, 2 Jul 2020 17:37:48 +0100 [thread overview]
Message-ID: <20200702163748.GA1125675@google.com> (raw)
In-Reply-To: <jhjfta9994q.mognet@arm.com>
On Thursday 02 Jul 2020 at 17:25:41 (+0100), Valentin Schneider wrote:
> It's actually pretty close to what happens with the LLC domain on SMP -
> select_idle_sibling() doesn't look outside of it. The wake_affine() stuff
> might steer the task towards a different LLC, but that's about it for
> wakeups. We rely on load balancing (fork/exec, newidle, nohz and periodic)
> to spread this further - and we would here too.
Sure, but on SMP the search space in select_idle_sibling is always
consistent -- you search within the LLC. With the fix you suggested,
CPUs 0-3 will search within their LLCs, while CPU4 searches the entire
system, which creates an imbalanced mess IMO.
For affine wake-ups, you could migrate from CPU4 -> CPU0-3, but CPU0-3
to CPU4 is not possible, so this asymmetry is almost guaranteed to
actively create imbalance. And sure, the periodic load balancer ought to
fix it, but really wake-up balance and periodic load balance should be
pushing in the same direction and not fighting against each other.
Anyways, enough bikeshedding for today, I'll try and have look at the
rest of the series :)
Cheers,
Quentin
next prev parent reply other threads:[~2020-07-02 16:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 19:06 [PATCH v3 0/7] sched: Instrument sched domain flags Valentin Schneider
2020-07-01 19:06 ` [PATCH v3 1/7] sched/topology: Split out SD_* flags declaration to its own file Valentin Schneider
2020-07-01 19:06 ` [PATCH v3 2/7] sched/topology: Define and assign sched_domain flag metadata Valentin Schneider
2020-07-02 12:15 ` Quentin Perret
2020-07-02 14:31 ` Valentin Schneider
2020-07-02 15:45 ` Quentin Perret
2020-07-02 16:25 ` Valentin Schneider
2020-07-02 16:37 ` Quentin Perret [this message]
2020-07-02 16:49 ` Valentin Schneider
2020-07-01 19:06 ` [PATCH v3 3/7] sched/topology: Verify SD_* flags setup when sched_debug is on Valentin Schneider
2020-07-02 14:20 ` Peter Zijlstra
2020-07-02 14:32 ` Valentin Schneider
2020-07-01 19:06 ` [PATCH v3 4/7] arm, sched/topology: Remove SD_SHARE_POWERDOMAIN Valentin Schneider
2020-07-02 16:44 ` Dietmar Eggemann
2020-07-02 18:46 ` Valentin Schneider
2020-07-01 19:06 ` [PATCH v3 5/7] sched/topology: Add more flags to the SD degeneration mask Valentin Schneider
2020-07-02 18:28 ` Dietmar Eggemann
2020-07-01 19:06 ` [PATCH v3 6/7] sched/topology: Introduce SD metaflag for flags needing > 1 groups Valentin Schneider
2020-07-02 18:29 ` Dietmar Eggemann
2020-07-02 18:46 ` Valentin Schneider
2020-07-13 12:39 ` Peter Zijlstra
2020-07-13 13:25 ` Valentin Schneider
2020-07-01 19:06 ` [PATCH v3 7/7] sched/topology: Use prebuilt SD flag degeneration mask Valentin Schneider
2020-07-13 12:55 ` Peter Zijlstra
2020-07-13 13:28 ` Valentin Schneider
2020-07-13 13:43 ` Peter Zijlstra
2020-07-13 13:52 ` 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=20200702163748.GA1125675@google.com \
--to=qperret@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--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