>>> On 21.01.15 at 15:28, <george.dun...@eu.citrix.com> 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 <jbeul...@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.)
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@lists.xen.org
http://lists.xen.org/xen-devel
