Re: [Xen-devel] [PATCH] introduce and used relaxed cpumask operations

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.01.15 at 15:28, <george.dunlap@xxxxxxxxxxxxx> wrote:
> 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@xxxxxxxx>
> 
> 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.)

Makes a lot of sense, except that it means even more typing.

>> @@ -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.

Already done in response to Andrew's similar request.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel