All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Keir Fraser <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>
Subject: Re: [PATCH] introduce and used relaxed cpumask operations
Date: Wed, 21 Jan 2015 14:28:05 +0000	[thread overview]
Message-ID: <54BFB775.7030702@eu.citrix.com> (raw)
In-Reply-To: <54BD379C0200007800056965@mail.emea.novell.com>

On 01/19/2015 03:58 PM, Jan Beulich wrote:
> Using atomic (LOCKed on x86) bitops for certain of the operations on
> cpumask_t is overkill when the variables aren't concurrently accessible
> (e.g. local function variables, or due to explicit locking). Introduce
> alternatives using non-atomic bitops and use them where appropriate.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I'm wondering if it might be sensible to have more informative names for
these, that would make it easier for coders / reviewers to see what
aspect makes the cpumask suitable for the relaxed access; for instance,
"local_cpumask_set_cpu()" for local variables, and
"locked_cpumask_set_cpu()" for  cpumasks which we know are locked.  (Or
perhaps cpumask_set_cpu_local and cpumask_set_cpu_locked.)

At some point some clever person might even be able to write some
Coverity rules that check to make sure cpumask_set_cpu_local only
accesses local variables, &c.


> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -372,7 +372,7 @@ __runq_tickle(unsigned int cpu, struct c
>      {
>          if ( cur->pri != CSCHED_PRI_IDLE )
>              SCHED_STAT_CRANK(tickle_idlers_none);
> -        cpumask_set_cpu(cpu, &mask);
> +        __cpumask_set_cpu(cpu, &mask);
>      }
>      else if ( !idlers_empty )
>      {
> @@ -422,7 +422,7 @@ __runq_tickle(unsigned int cpu, struct c
>                  SCHED_VCPU_STAT_CRANK(cur, migrate_r);
>                  SCHED_STAT_CRANK(migrate_kicked_away);
>                  set_bit(_VPF_migrating, &cur->vcpu->pause_flags);
> -                cpumask_set_cpu(cpu, &mask);
> +                __cpumask_set_cpu(cpu, &mask);
>              }
>              else if ( !new_idlers_empty )
>              {
> @@ -432,7 +432,7 @@ __runq_tickle(unsigned int cpu, struct c
>                  {
>                      this_cpu(last_tickle_cpu) =
>                          cpumask_cycle(this_cpu(last_tickle_cpu), &idle_mask);
> -                    cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
> +                    __cpumask_set_cpu(this_cpu(last_tickle_cpu), &mask);
>                  }
>                  else
>                      cpumask_or(&mask, &mask, &idle_mask);
> @@ -675,7 +675,7 @@ _csched_cpu_pick(const struct scheduler 
>           */
>          cpumask_and(&idlers, &cpu_online_map, CSCHED_PRIV(ops)->idlers);
>          if ( vc->processor == cpu && IS_RUNQ_IDLE(cpu) )
> -            cpumask_set_cpu(cpu, &idlers);
> +            __cpumask_set_cpu(cpu, &idlers);
>          cpumask_and(&cpus, &cpus, &idlers);
>  
>          /*
> @@ -692,7 +692,7 @@ _csched_cpu_pick(const struct scheduler 
>           */
>          if ( !cpumask_test_cpu(cpu, &cpus) && !cpumask_empty(&cpus) )
>              cpu = cpumask_cycle(cpu, &cpus);
> -        cpumask_clear_cpu(cpu, &cpus);
> +        __cpumask_clr_cpu(cpu, &cpus);
>  
>          while ( !cpumask_empty(&cpus) )
>          {
> @@ -1536,7 +1536,7 @@ csched_load_balance(struct csched_privat
>              /* Find out what the !idle are in this node */
>              cpumask_andnot(&workers, online, prv->idlers);
>              cpumask_and(&workers, &workers, &node_to_cpumask(peer_node));
> -            cpumask_clear_cpu(cpu, &workers);
> +            __cpumask_clr_cpu(cpu, &workers);
>  
>              peer_cpu = cpumask_first(&workers);
>              if ( peer_cpu >= nr_cpu_ids )

All these look good, but...

> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -663,7 +663,7 @@ burn_budget(const struct scheduler *ops,
>   * lock is grabbed before calling this function
>   */
>  static struct rt_vcpu *
> -__runq_pick(const struct scheduler *ops, cpumask_t *mask)
> +__runq_pick(const struct scheduler *ops, const cpumask_t *mask)
>  {
>      struct list_head *runq = rt_runq(ops);
>      struct list_head *iter;
> @@ -780,10 +780,7 @@ rt_schedule(const struct scheduler *ops,
>      }
>      else
>      {
> -        cpumask_t cur_cpu;
> -        cpumask_clear(&cur_cpu);
> -        cpumask_set_cpu(cpu, &cur_cpu);
> -        snext = __runq_pick(ops, &cur_cpu);
> +        snext = __runq_pick(ops, cpumask_of(cpu));
>          if ( snext == NULL )
>              snext = rt_vcpu(idle_vcpu[cpu]);
>  

This bit really needs explicit mention in the changelog.

 -George

  parent reply	other threads:[~2015-01-21 14:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19 15:58 [PATCH] introduce and used relaxed cpumask operations Jan Beulich
2015-01-21 12:21 ` Andrew Cooper
2015-01-21 14:10   ` Jan Beulich
2015-01-22 15:29     ` Tim Deegan
2015-01-21 14:28 ` George Dunlap [this message]
2015-01-21 14:35   ` Jan Beulich
2015-01-21 14:42     ` George Dunlap
2015-01-21 15:06       ` Jan Beulich
2015-01-21 15:10         ` George Dunlap

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=54BFB775.7030702@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.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.