[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Yuehai Xu <yuehaixu@xxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
  • Date: Thu, 30 Sep 2010 14:27:37 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, yhxu@xxxxxxxxx
  • Delivery-date: Thu, 30 Sep 2010 06:28:29 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=GxadfqDYhHz38aytbTETTMGyMG539dFEEH67Oe0FaYKLLSuu8CtYXAR2AkAp6YragG zYwv1w6RmVdGOhlC55fxH1zw3TJUIPKeGCHZ2j3Rl6Npb8EGhNxSCHWjjHls/WxCCieF ndJmW5mbl2S3SmGIu378+CxEmn0jSIo7pmf4M=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.