The general mechanism and interface to the new scheduler will be the
same as the old: weight, credits, &c. Just a lot of the plumbing will
be re-worked. It may be a big enough to start a new scheduler,
"credit2", while the kinks get worked out; we'll see.
For those who are using cap to provide QoS: I'm going to be adding a
new feature, a complement to the "cap" feature, which would be a
"floor" or "reservation" feature. (Haven't thought of a good name for
it yet.) Just as "cap" will make sure that a given VM never uses more
than X% of a cpu, the "reservation" feature will ensure that a VM can
always get Y% of a cpu if it wants it. It seems like this may be
closer to what you want -- guarantee a minimum QoS, but allow VMs to
use extra resources if they're available?
At any rate, the cap feature shouldn't be to difficult to keep, so
since people are still using it, I'll do the bit of extra work to keep
it in the new system. Thanks for the input, all!
Peace,
 -George
On Wed, Jan 21, 2009 at 9:30 AM, Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx> wrote:
> Hi, George
>
> Of course I use "cap".
>
> Would you explain the parameter(s) in your scheduler?
> (keep two or ???)
>
> Thanks
> Atsushi SAKAI
>
>
> George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
>
>> I'm in the process of revising the credit scheduler design, and I'd
>> like to know how important it is to maintain the "cap" functionality
>> of the credit scheduler. If you use it, or know of someone who does,
>> could you let me know?
>>
>> If you don't know what it is, you probably aren't using it. :-)
>>
>> Peace,
>> -George
>>
>> _______________________________________________
>> 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 
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel