From: Peter Zijlstra <peterz@infradead.org>
To: Valentin Schneider <valentin.schneider@arm.com>
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 15:43:47 +0200 [thread overview]
Message-ID: <20200713134347.GL10769@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <jhjimerlf2a.mognet@arm.com>
On Mon, Jul 13, 2020 at 02:28:29PM +0100, Valentin Schneider wrote:
>
> 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.
Oh, right, I forgot we have NODE, d'0h. But in that case these lines:
if (nr_node_ids == 1)
pflags &= ~SD_SERIALIZE;
are dead code, right?
> > 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.
Man, that's horrible :-) OK, fair enough, keep it as is, we'll see what
if anything breaks.
next prev parent reply other threads:[~2020-07-13 13:43 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
2020-07-13 13:43 ` Peter Zijlstra [this message]
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=20200713134347.GL10769@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--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 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.