This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Question about the ability of credit scheduler to handle

To: Yuehai Xu <yuehaixu@xxxxxxxxx>
Subject: Re: [Xen-devel] Question about the ability of credit scheduler to handle I/O and CPU intensive VMs
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5dhSxvfi46LVj7+HicbIPpGT80nd34OVA9XjEfLbMdg=; b=FjE1/FvbRk1xqjQqRyKPforZkXJjiqBtFALd5QNHhbvH860ZJ05BYNGgvWyHZi5p1N 8veDf8fskv86/rC8qhaTwC7W/GLArlrcTwkp61wGyrDzJOpdzW6xv7iQxkzgUwwzKsVS uRyudQ2GE8z9/oPQXcEgqPPHuoz39ZHvsi0wk=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTikBWZdpOviSEQSNi_pf66A+zYW8FyQVjiCX8ojm@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTi=Ro24zg-yDPk1+=c0XsZSe2kNn8Gk07Bu4x0WN@xxxxxxxxxxxxxx> <AANLkTin9E1m_jFcj4Ak7nB9OxcQynrznpQ_nNPi_U7hN@xxxxxxxxxxxxxx> <AANLkTikBWZdpOviSEQSNi_pf66A+zYW8FyQVjiCX8ojm@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

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.


> 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