From: Ingo Molnar <mingo@kernel.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
morten.rasmussen@arm.com, Quentin Perret <qperret@google.com>
Subject: Re: [PATCH v4 05/10] sched/topology: Define and assign sched_domain flag metadata
Date: Thu, 6 Aug 2020 16:07:50 +0200 [thread overview]
Message-ID: <20200806140750.GC2077896@gmail.com> (raw)
In-Reply-To: <20200731115502.12954-6-valentin.schneider@arm.com>
* Valentin Schneider <valentin.schneider@arm.com> wrote:
> +#ifndef SD_FLAG
> +#define SD_FLAG(x, y, z)
> +#endif
AFAICS there's not a single use of sd_flags.h that doesn't come with
its own SD_FLAG definition, so I suppose this should be:
#ifndef SD_FLAG
# error "Should not happen."
#endif
?
Also, some nits:
> +/*
> + * Expected flag uses
> + *
> + * SHARED_CHILD: These flags are meant to be set from the base domain upwards.
> + * If a domain has this flag set, all of its children should have it set. This
> + * is usually because the flag describes some shared resource (all CPUs in that
> + * domain share the same foobar), or because they are tied to a scheduling
> + * behaviour that we want to disable at some point in the hierarchy for
> + * scalability reasons.
s/foobar/resource
?
> +/*
> + * cross-node balancing
> + *
> + * SHARED_PARENT: Set for all NUMA levels above NODE.
> + */
> +SD_FLAG(SD_NUMA, 12, SDF_SHARED_PARENT)
s/cross-node/Cross-node
BTW., is there any particular reason why these need to be defines with
a manual enumeration of flag values - couldn't we generate
auto-enumerated C enums instead or so?
> +#ifdef CONFIG_SCHED_DEBUG
> +#define SD_FLAG(_name, idx, mflags) [idx] = {.meta_flags = mflags, .name = #_name},
s/{./{ .
s/e}/e }
Thanks,
Ingo
next prev parent reply other threads:[~2020-08-06 17:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 11:54 [PATCH v4 00/10] sched: Instrument sched domain flags Valentin Schneider
2020-07-31 11:54 ` [PATCH v4 01/10] ARM, sched/topology: Remove SD_SHARE_POWERDOMAIN Valentin Schneider
2020-07-31 11:54 ` [PATCH v4 02/10] ARM: Revert back to default scheduler topology Valentin Schneider
2020-07-31 11:54 ` [PATCH v4 03/10] sched/topology: Propagate SD_ASYM_CPUCAPACITY upwards Valentin Schneider
2020-08-06 14:20 ` Ingo Molnar
2020-08-06 16:19 ` Valentin Schneider
2020-08-06 16:46 ` Ingo Molnar
2020-07-31 11:54 ` [PATCH v4 04/10] sched/topology: Split out SD_* flags declaration to its own file Valentin Schneider
2020-07-31 11:54 ` [PATCH v4 05/10] sched/topology: Define and assign sched_domain flag metadata Valentin Schneider
2020-08-04 11:08 ` peterz
2020-08-04 11:12 ` Valentin Schneider
2020-08-06 14:07 ` Ingo Molnar [this message]
2020-08-06 16:18 ` Valentin Schneider
2020-08-08 0:19 ` Valentin Schneider
2020-07-31 11:54 ` [PATCH v4 06/10] sched/topology: Verify SD_* flags setup when sched_debug is on Valentin Schneider
2020-07-31 11:54 ` [PATCH v4 07/10] sched/topology: Add more flags to the SD degeneration mask Valentin Schneider
2020-08-06 13:57 ` Ingo Molnar
2020-07-31 11:55 ` [PATCH v4 08/10] sched/topology: Remove SD_SERIALIZE degeneration special case Valentin Schneider
2020-07-31 11:55 ` [PATCH v4 09/10] sched/topology: Introduce SD metaflag for flags needing > 1 groups Valentin Schneider
2020-07-31 11:55 ` [PATCH v4 10/10] sched/topology: Use prebuilt SD flag degeneration mask Valentin Schneider
2020-08-06 11:25 ` [PATCH v4 00/10] sched: Instrument sched domain flags Dietmar Eggemann
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=20200806140750.GC2077896@gmail.com \
--to=mingo@kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=qperret@google.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.