All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Ingo Molnar <mingo@kernel.org>
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: Sat, 08 Aug 2020 01:19:24 +0100	[thread overview]
Message-ID: <jhj1rkihtv7.mognet@arm.com> (raw)
In-Reply-To: <jhj8serixd4.mognet@arm.com>


On 06/08/20 17:18, Valentin Schneider wrote:
> In the grand scheme of things I'd actually like to have this file output
> the names of the flags rather than their values (since I now save them when
> SCHED_DEBUG=y), but I didn't find a simple way to hack the existing SD ctl
> table (sd_alloc_ctl_domain_table() and co) into doing this.
>

I "just" had to spend some more time grokking how the whole ctl
proc_handler thing is supposed to work; I now have a mostly working
solution, i.e. on my Juno:

  $ cat /proc/sys/kernel/sched_domain/cpu0/domain*/flags
  SD_BALANCE_NEWIDLE SD_BALANCE_EXEC SD_BALANCE_FORK SD_WAKE_AFFINE SD_SHARE_PKG_RESOURCES
  SD_BALANCE_NEWIDLE SD_BALANCE_EXEC SD_BALANCE_FORK SD_WAKE_AFFINE SD_ASYM_CPUCAPACITY SD_PREFER_SIBLING

I'll clean that up and go for the automagic ordering I previously
described.

>
> Now as to making this fully automagic, I *think* I could do something like
> having a first enum to set up an ordering:
>
>   #define SD_FLAG(name, ...) __##name,
>   enum {
>     #include <linux/sched/sd_flags.h>
>   };
>
> A second one to have powers of 2:
>
>   #define SD_FLAG(name, ...) name = 1 << __##name,
>   enum {
>     #include <linux/sched/sd_flags.h>
>   };
>
> And finally the metadata array assignment might be doable with:
>
>   #define SD_FLAG(_name, mflags) [__##_name] = { .meta_flags = mflags, .name = #_name },
>
> Or, if there is a way somehow to directly get powers of 2 out of an enum:
>
>   #define SD_FLAG(_name, mflags) [_ffs(_name)] = { .meta_flags = mflags, .name = #_name },
>
>>> +#ifdef CONFIG_SCHED_DEBUG
>>> +#define SD_FLAG(_name, idx, mflags) [idx] = {.meta_flags = mflags, .name = #_name},
>>
>> s/{./{ .
>> s/e}/e }
>>
>> Thanks,
>>
>>       Ingo

  reply	other threads:[~2020-08-08  0:19 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
2020-08-06 16:18     ` Valentin Schneider
2020-08-08  0:19       ` Valentin Schneider [this message]
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=jhj1rkihtv7.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=qperret@google.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.