From: Valentin Schneider <valentin.schneider@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
morten.rasmussen@arm.com
Subject: Re: [PATCH v3 7/7] sched/topology: Use prebuilt SD flag degeneration mask
Date: Mon, 13 Jul 2020 14:28:29 +0100 [thread overview]
Message-ID: <jhjimerlf2a.mognet@arm.com> (raw)
In-Reply-To: <20200713125543.GJ10769@hirez.programming.kicks-ass.net>
On 13/07/20 13:55, Peter Zijlstra wrote:
> On Wed, Jul 01, 2020 at 08:06:55PM +0100, Valentin Schneider wrote:
>> Leverage SD_DEGENERATE_GROUPS_MASK in sd_degenerate() and
>> sd_degenerate_parent().
>>
>> Note that this changes sd_degenerate() somewhat: I'm using the negation of
>> SD_DEGENERATE_GROUPS_MASK as the mask of flags not requiring groups, which
>> is equivalent to:
>>
>> SD_WAKE_AFFINE | SD_SERIALIZE | SD_NUMA
>>
>> whereas the current mask for that is simply
>>
>> SD_WAKE_AFFINE
>>
>> I played with a few toy NUMA topologies on QEMU and couldn't cause a
>> different degeneration than what mainline does currently. If that is deemed
>> too risky, we can go back to using SD_WAKE_AFFINE explicitly.
>
> Arguably SD_SERIALIZE needs groups, note how we're only having that
> effective for machines with at least 2 nodes. It's a bit shit how we end
> up there, but IIRC that's what it ends up as.
>
Right, AFAICT we get SD_SERIALIZE wherever we have SD_NUMA, which is any
level above NODE.
> SD_NUMA is descriptive, and not marking a group as degenerates because
> it has SD_NUMA seems a bit silly.
It does, although we can still degenerate it, see below.
> But then, it would be the top domain
> and would survive anyway?
So from what I've tested we still get rid of those via
sd_parent_degenerate(): child and parent have the same flags and same span,
so parent goes out.
That happens in the middle of the NUMA topology levels on that borked
topology with weird distances, aka
node distances:
node 0 1 2 3
0: 10 12 20 22
1: 12 10 22 24
2: 20 22 10 12
3: 22 24 12 10
which ought to look something like (+local distance to end result)
2 10 2
1 <---> 0 <---> 2 <---> 3
We end up with the following NUMA levels (i.e. deduplicated distances)
NUMA (<= 12)
NUMA (<= 20)
NUMA (<= 22)
NUMA (<= 24)
For e.g. any CPU of node1, NUMA(<=20) is gonna have the same span as
NUMA(<=12), so we'll degenerate it.
next prev parent reply other threads:[~2020-07-13 13:28 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
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 [this message]
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=jhjimerlf2a.mognet@arm.com \
--to=valentin.schneider@arm.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=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