Re: [Xen-devel] Question about the ability of credit scheduler to handle I/O and CPU intensive VMs

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Sep 30, 2010 at 1:28 PM, Yuehai Xu <yuehaixu@xxxxxxxxx> wrote:
>> I agree, letting a VM with an interrupt run for a short period of time
>> makes sense.  The challenge is to make sure that it can't simply send
>> itself interrupts every 50us and get to run 100% of the time. :-)
>
> I am afraid I don't really understand the challenge is, or, in another
> word, this method is good principally, but in practice, it is hard to
> implement? As I know, the OS should always schedules I/O related
> processes once they are in runnable queue, so, as long as we give even
> a very short period of time to the waken up guest VM, the I/O process
> in it should be scheduled at once. In that case, this problem should
> be solved. Of course, I don't do experiments, saying is always much
> easier than doing.

What I mean is that you have to be careful when implementing it.  A
very simple implementation would look like this:
* Normally, let the VM with the highest credits run.  However, if a VM
is sent an interrupt, give it priority to run for 50us.

Now, suppose, however, that a rogue VM sets up a periodic timer to
send itself an interrupt every 55us.  Then it will get an interrupt,
get priority for 50us, be preempted for 5us, and then get another
interrupt, allowing it to run for another 50us.    Thus it runs 90% of
the time, even though it should only run (for example) 50% of the
time.

We need a way to balance interrupt latency (how long after an
interrupt is raised before a VM can run) and cpu scheduling fairness.
That means that if we let a VM run for 50us, and then preempt it, and
it gets an interrupt 5us later, we need a way to know not to schedule
it until it's been off the cpu for a reasonable amount of time.  It's
possible, but it will take some experimentation to see what the best
option is.

 -George

>
> Thanks,
> Yuehai
>>
>> I don't have time to work on this right now, but if you work up some
>> patches, I can give you feedback.  Be advised, that getting this stuff
>> to work right is not easy.
>>
>>  -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