|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 03 of 11 v4] xen: sched_credit: when picking, make sure we get an idle one, if any
>>> On 15.03.13 at 11:37, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
> On ven, 2013-03-15 at 08:14 +0000, Jan Beulich wrote:
> Perhaps I can turn the condition into something like this:
>
> if ( !cpumask_test_cpu(cpu, &cpus) )
> cpu = cpumask_empty(&cpus) ? cpu : cpumask_cycle(cpu, &cpus);
>
> So that we pay the price less frequently?
Given cpu < nr_cpu_ids before this, yes, that sounds right. Or
you could simply switch the operands of the && in your original
if(). Yet less expensive would be if you stored the result of
cpumask_cycle() in another variable and copied it into "cpu"
only if less than nr_cpu_ids. That would eliminate the need for
cpumask_empty() altogether.
>> The ASSERT() a few lines earlier
>> could be simplified in similar ways, btw.
>>
> You mean this, right?
>
> online = cpupool_scheduler_cpumask(vc->domain->cpupool);
> cpumask_and(&cpus, online, vc->cpu_affinity);
> cpu = cpumask_test_cpu(vc->processor, &cpus)
> ? vc->processor
> : cpumask_cycle(vc->processor, &cpus);
> ASSERT( !cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus) );
>
> Not sure. AFAIU the code, the ASSERT() is indeed willing to make sure
> that cpus did not ended up being empty as a consequence of the
> cpumask_and(), and that is done together with the cpumask_test_cpu()
> just to have only one ASSERT() instead of two, but again, I might well
> be wrong.
If I'm not mistaken,
ASSERT(cpu < nr_cpu_ids && cpumask_test_cpu(cpu, &cpus));
would have the exact same effect.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |