All of lore.kernel.org
 help / color / mirror / Atom feed
From: Beata Michalska <beata.michalska@arm.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
	mingo@redhat.com, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, valentin.schneider@arm.com,
	corbet@lwn.net, rdunlap@infradead.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v5 2/3] sched/topology: Rework CPU capacity asymmetry detection
Date: Tue, 25 May 2021 10:30:39 +0100	[thread overview]
Message-ID: <20210525093039.GA31871@e120325.cambridge.arm.com> (raw)
In-Reply-To: <cdb4e3a4-569f-1dc2-be22-c0128250996a@arm.com>

On Tue, May 25, 2021 at 10:25:36AM +0200, Dietmar Eggemann wrote:
> On 24/05/2021 12:16, Beata Michalska wrote:
> 
> [...]
> 
> > Rework the way the capacity asymmetry levels are being detected,
> > allowing to point to the lowest topology level (for a given CPU), where
> > full set of available CPU capacities is visible to all CPUs within given
> > domain. As a result, the per-cpu sd_asym_cpucapacity might differ across
> > the domains. This will have an impact on EAS wake-up placement in a way
> > that it might see different rage of CPUs to be considered, depending on
> 
> s/rage/range ;-)
Right ..... :)
> 
> [...]
> 
> > @@ -1266,6 +1266,112 @@ static void init_sched_groups_capacity(int cpu, struct sched_domain *sd)
> >  	update_group_capacity(sd, cpu);
> >  }
> >  
> > +/**
> > + * Asymmetric CPU capacity bits
> > + */
> > +struct asym_cap_data {
> > +	struct list_head link;
> > +	unsigned long    capacity;
> > +	struct cpumask   *cpu_mask;
> 
> Not sure if this has been discussed already but shouldn't the flexible
> array members` approach known from struct sched_group, struct
> sched_domain or struct em_perf_domain be used here?
> IIRC the last time this has been discussed in this thread:
> https://lkml.kernel.org/r/20200910054203.525420-2-aubrey.li@intel.com
> 
If I got right the discussion you have pointed to, it was about using
cpumask_var_t which is not the case here. I do not mind moving the code
to use the array but I am not sure if this changes much. Looking at the
code changes to support that (to_cpumask namely) it was introduced for
cases where cpumask_var_t was not appropriate, which again isn't the case
here.

---
BR
B.
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 0de6eef91bc8..03e492e91bd7 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -1271,8 +1271,8 @@ static void init_sched_groups_capacity(int cpu,
> struct sched_domain *sd)
>   */
>  struct asym_cap_data {
>         struct list_head link;
> -       unsigned long    capacity;
> -       struct cpumask   *cpu_mask;
> +       unsigned long capacity;
> +       unsigned long cpumask[];
>  };
> 
>  /*
> @@ -1299,14 +1299,14 @@ asym_cpu_capacity_classify(struct sched_domain *sd,
>                 goto leave;
> 
>         list_for_each_entry(entry, &asym_cap_list, link) {
> -               if (cpumask_intersects(sched_domain_span(sd),
> entry->cpu_mask)) {
> +               if (cpumask_intersects(sched_domain_span(sd),
> to_cpumask(entry->cpumask))) {
>                         ++asym_cap_count;
>                 } else {
>                         /*
>                          * CPUs with given capacity might be offline
>                          * so make sure this is not the case
>                          */
> -                       if (cpumask_intersects(entry->cpu_mask, cpu_map)) {
> +                       if
> (cpumask_intersects(to_cpumask(entry->cpumask), cpu_map)) {
>                                 sd_asym_flags &= ~SD_ASYM_CPUCAPACITY_FULL;
>                                 if (asym_cap_count > 1)
>                                         break;
> @@ -1332,7 +1332,6 @@ asym_cpu_capacity_get_data(unsigned long capacity)
>         if (WARN_ONCE(!entry, "Failed to allocate memory for asymmetry
> data\n"))
>                 goto done;
>         entry->capacity = capacity;
> -       entry->cpu_mask = (struct cpumask *)((char *)entry +
> sizeof(*entry));
>         list_add(&entry->link, &asym_cap_list);
>  done:
>         return entry;
> @@ -1349,7 +1348,7 @@ static void asym_cpu_capacity_scan(void)
>         int cpu;
> 
>         list_for_each_entry(entry, &asym_cap_list, link)
> -               cpumask_clear(entry->cpu_mask);
> +               cpumask_clear(to_cpumask(entry->cpumask));
> 
>         entry = list_first_entry_or_null(&asym_cap_list,
>                                          struct asym_cap_data, link);
> @@ -1361,11 +1360,11 @@ static void asym_cpu_capacity_scan(void)
>                 if (!entry || capacity != entry->capacity)
>                         entry = asym_cpu_capacity_get_data(capacity);
>                 if (entry)
> -                       __cpumask_set_cpu(cpu, entry->cpu_mask);
> +                       __cpumask_set_cpu(cpu, to_cpumask(entry->cpumask));
>         }
> 
>         list_for_each_entry_safe(entry, next, &asym_cap_list, link) {
> -               if (cpumask_empty(entry->cpu_mask)) {
> +               if (cpumask_empty(to_cpumask(entry->cpumask))) {
>                         list_del(&entry->link);
>                         kfree(entry);
>                 }
> 
> [...]

  reply	other threads:[~2021-05-25  9:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24 10:16 [PATCH v5 0/3] Rework CPU capacity asymmetry detection Beata Michalska
2021-05-24 10:16 ` [PATCH v5 1/3] sched/core: Introduce SD_ASYM_CPUCAPACITY_FULL sched_domain flag Beata Michalska
2021-05-24 10:16 ` [PATCH v5 2/3] sched/topology: Rework CPU capacity asymmetry detection Beata Michalska
2021-05-24 18:01   ` Valentin Schneider
2021-05-24 22:55     ` Beata Michalska
2021-05-24 23:19       ` Beata Michalska
2021-05-25  9:53       ` Valentin Schneider
2021-05-25 10:29         ` Beata Michalska
2021-05-26  9:52           ` Dietmar Eggemann
2021-05-26 12:15             ` Beata Michalska
2021-05-26 12:51               ` Beata Michalska
2021-05-26 18:17                 ` Dietmar Eggemann
2021-05-26 21:40                   ` Beata Michalska
2021-05-27 15:08                     ` Dietmar Eggemann
2021-05-27 17:07                       ` Beata Michalska
2021-06-02 17:17                         ` Dietmar Eggemann
2021-06-02 19:48                           ` Beata Michalska
2021-06-03  9:09                             ` Dietmar Eggemann
2021-06-03  9:24                               ` Beata Michalska
2021-05-26 18:17               ` Dietmar Eggemann
2021-05-26 21:43                 ` Beata Michalska
2021-05-27  7:03             ` Peter Zijlstra
2021-05-27 12:22               ` Dietmar Eggemann
2021-05-27 12:32                 ` Beata Michalska
2021-05-25  8:25   ` Dietmar Eggemann
2021-05-25  9:30     ` Beata Michalska [this message]
2021-05-25 11:59       ` Dietmar Eggemann
2021-05-25 14:04         ` Beata Michalska
2021-05-24 10:16 ` [PATCH v5 3/3] sched/doc: Update the CPU capacity asymmetry bits Beata Michalska

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=20210525093039.GA31871@e120325.cambridge.arm.com \
    --to=beata.michalska@arm.com \
    --cc=corbet@lwn.net \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --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.