From: Valentin Schneider <valentin.schneider@arm.com>
To: Qais Yousef <qais.yousef@arm.com>
Cc: "Li\, Aubrey" <aubrey.li@linux.intel.com>,
Aubrey Li <aubrey.li@intel.com>,
mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 1/1] sched/fair: select idle cpu from idle cpumask in sched domain
Date: Mon, 14 Sep 2020 12:26:47 +0100 [thread overview]
Message-ID: <jhjk0ww61l4.mognet@arm.com> (raw)
In-Reply-To: <20200914110809.2nu7vt2s3lzlvxoz@e107158-lin.cambridge.arm.com>
On 14/09/20 12:08, Qais Yousef wrote:
> On 09/14/20 11:31, Valentin Schneider wrote:
>>
>> On 12/09/20 00:04, Li, Aubrey wrote:
>> >>> +++ b/include/linux/sched/topology.h
>> >>> @@ -65,8 +65,21 @@ struct sched_domain_shared {
>> >>> atomic_t ref;
>> >>> atomic_t nr_busy_cpus;
>> >>> int has_idle_cores;
>> >>> + /*
>> >>> + * Span of all idle CPUs in this domain.
>> >>> + *
>> >>> + * NOTE: this field is variable length. (Allocated dynamically
>> >>> + * by attaching extra space to the end of the structure,
>> >>> + * depending on how many CPUs the kernel has booted up with)
>> >>> + */
>> >>> + unsigned long idle_cpus_span[];
>> >>
>> >> Can't you use cpumask_var_t and zalloc_cpumask_var() instead?
>> >
>> > I can use the existing free code. Do we have a problem of this?
>> >
>>
>> Nah, flexible array members are the preferred approach here; this also
>
> Is this your opinion or a rule written somewhere I missed?
I don't think there's a written rule, but AIUI it is preferred by at
least Peter:
https://lore.kernel.org/linux-pm/20180612125930.GP12217@hirez.programming.kicks-ass.net/
https://lore.kernel.org/lkml/20180619110734.GO2458@hirez.programming.kicks-ass.net/
And my opinion is that, if you can, having fewer separate allocation is better.
>
>> means we don't let CONFIG_CPUMASK_OFFSTACK dictate where this gets
>> allocated.
>>
>> See struct numa_group, struct sched_group, struct sched_domain, struct
>> em_perf_domain...
>
> struct root_domain, struct cpupri_vec, struct generic_pm_domain,
> struct irq_common_data..
>
> Use cpumask_var_t.
>
> Both approach look correct to me, so no objection in principle. cpumask_var_t
> looks neater IMO and will be necessary once more than one cpumask are required
> in a struct.
>
You're right in that cpumask_var_t becomes necessary when you need more
than one mask. For those that use it despite requiring only one mask
(cpupri stuff, struct nohz too), I'm not sure.
next prev parent reply other threads:[~2020-09-14 11:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 5:42 [RFC PATCH v1 0/1] " Aubrey Li
2020-09-10 5:42 ` [RFC PATCH v1 1/1] sched/fair: " Aubrey Li
2020-09-11 16:28 ` Qais Yousef
2020-09-11 23:04 ` Li, Aubrey
2020-09-11 23:16 ` Li, Aubrey
2020-09-14 10:31 ` Valentin Schneider
2020-09-14 11:08 ` Qais Yousef
2020-09-14 11:26 ` Valentin Schneider [this message]
2020-09-14 11:31 ` Qais Yousef
2020-09-13 3:59 ` Jiang Biao
2020-09-14 12:26 ` Vincent Guittot
2020-09-15 8:47 ` Jiang Biao
2020-09-15 9:23 ` Vincent Guittot
2020-09-15 13:38 ` Li, Aubrey
2020-09-14 12:32 ` Vincent Guittot
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=jhjk0ww61l4.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=aubrey.li@intel.com \
--cc=aubrey.li@linux.intel.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@linux.intel.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
Powered by JetHome