If we wanted to be clever, we could rely upon the fact that this
condition only happens when credit > CSCHED_CREDITS_PER_TSLICE, which
is a positive value.
But I'm all for being defensive and using /= 2 instead.
-George
On Mon, Aug 9, 2010 at 1:31 PM, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote:
> Hi,
>
> At 12:38 +0100 on 09 Aug (1281357513), George Dunlap wrote:
>> VMs that don't use their full timeslice are guaranteed to flip back
>> and forth between "active" and "inactive". If we set credit to 0
>> when setting "inactive", then when the VM comes back to "active"
>> again, it will effectively be behind most other vcpus in credit.
>> This causes the credit1 to effectively discriminate *against*
>> VMs which use less than their full timeslice.
>>
>> Instead of setting credit to 0, divide it in half (shifting
>> by one bit for more efficiency).
>
> "credit" here is signed, and the compiler is allowed to use either a
> signed or an unsigned shift for >>. Better to code it as /=2 and trust
> the compiler to DTRT with a constant division.
>
> Cheers,
>
> Tim.
>
>> This gets rid of some of the
>> system credit while allowing non-cpu-bound VMs to keep some priority
>> advantage.
>>
>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
>>
>> diff -r 6f07d9ac1e7c -r 1a29b22ef2e9 xen/common/sched_credit.c
>> --- a/xen/common/sched_credit.c Thu Aug 05 14:41:14 2010 +0100
>> +++ b/xen/common/sched_credit.c Mon Aug 09 12:38:12 2010 +0100
>> @@ -1069,7 +1069,9 @@
>> if ( credit > CSCHED_CREDITS_PER_TSLICE )
>> {
>> __csched_vcpu_acct_stop_locked(prv, svc);
>> - credit = 0;
>> + /* Divide credits in half, so that when it starts
>> + * accounting again, it starts a little bit "ahead" */
>> + credit >>= 1;
>> atomic_set(&svc->credit, credit);
>> }
>> }
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, XenServer Engineering
> Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|