[Xen-devel] RE: The caculation of the credit in credit_scheduler

["Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>]

George Dunlap wrote:
> Xiantao,
> 
> Thanks for your comments.  All of the things you pointed out are
> things 
> I'm trying to address in credit2.  In fact, a huge amount of them can
> be 
> attributed to the fact that credit1 divides tasks into 3 priorities
> (OVER, UNDER, and BOOST) and will schedule tasks "round-robin" within
> a 
> each priority.  Round-robin is known to discriminate against tasks
> which 
> yield (such as tasks that do frequent I/O) in favor of tasks that
> don't 
> yield (such as cpu "burners").
> In credit2, I hope to address these issues in a couple of ways:
> * Always sort the runqueue by order of credit.  This addresses issues
> in 
> all of 1, 2, and 3.
> * When a VM wakes up, update the credit of all the running VMs to see
> if 
> any of them should be preempted (addressing #3)
> * When selecting how long to run, I have a mechanism to look at the
> next 
> VM in the runqueue, and calculate how long it would take for the
> current 
> VM's credit to equal the next VM's credit.  I.e., if the one chosen to
> run has 10ms of credit, and the next one on the runqueue has 7ms of
> credit, set the schedule time to 3ms.  This is limited by a "minimum
> schedule time" (currently 500us) and a "maximum schedule time"
> (currently 10ms).  This could probably use some more tweaking, but it
> seem to work pretty well.
> 
> It's not clear to me how to address a lot of the issues you bring up
> without doing a big redesign -- which is what I'm already working on.
> 
> If you're interested in helping test / develop credit2, let me know,
> I'd 
> love some help. :-)
Hi, George
    Sorry for late reply! Glad to see you are addressing these issues in 
Credit2 and I also think sheduler is very performance-critical component in 
Xen, and it should impact the whole system's scalability and performance, 
especailly for large system. And we are also working on solving such issues and 
also glad to work with you and community to make the scheduler better and more 
friendly to large systems.  
Xiantao


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel