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: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Question about the ability of credit scheduler to handle I/O and CPU intensive VMs
From: Yuehai Xu <yuehaixu@xxxxxxxxx>
Date: Tue, 14 Sep 2010 10:58:31 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, yhxu@xxxxxxxxx
Delivery-date: Tue, 14 Sep 2010 08:00:13 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EmY3UNfSCVb3Zm16jNo+89Jr9WnrTxf3zb31umB5cXE=; b=Iy+KgCtdSSQMMDsA+rf7dRuv8JB5scley3P+2m5+bJ2rqc1BFOfotpxQFXPaGVedyu U+fhdVbS2PEWo//W8wJsqwhAJJg1HkNGoekO4NHTXxETltImpgo03QL0/vaoIs36nDgh e5SDzR7t9SARedDHBF2S9/bHWR6TcobM3L/9Y=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q1AMyHjaw+yHtYzN6KMwGHr3wwuTf90Z/ta7aA2lhG3FsfIyjAzaslfYZZ+Rcdpg3+ 9YIFjBcdtg9srIRVFNv5NKzAGSqmHoAEKrLrwGGsW4Xwqbck9hVoGbm7goPB82EKiljc ZIwZhqTK1mzjcNphlvn9+tGEk9nWFDXSjlqPE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTin9E1m_jFcj4Ak7nB9OxcQynrznpQ_nNPi_U7hN@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> 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. :-)

Do you mean that the real time for a VM to have PCPU is quite
uncertain in the case of 50us? I am not familiar with the code
structure, however, as I remembered, the guest kernel should schedule
I/O related process as soon as the completion of its request. For
example, CFS uses vruntime(the time to have CPU) to select the most
suitable process to schedule, and it is highly possible that I/O
process has less vruntime, which means it should preempt other current
process, and be scheduled immediately.

So, if we try to give a very short period of time, 50us for example,
even only 1/10 has been used, in the guest kernel, the I/O process in
VM should be scheduled and it can continuously dispatch requests, in
that way, the problem of I/O latency might be solved.

I am afraid I don't quite understand "..get to run 100% of the time",
I have tried credit2, but my computer can't boot successfully. I know
it is very very hard to debug the code since capture the error log is
difficult, or by remote serial console? I don't try it yet.

Once we give a very short period of time to VM which is waken up by
I/O event, is it possible that the problem of I/O latency be solved?
or the overhead for this frequent interrupt is too high to do this?
Or, no one has tried to test this idea because of difficult debug?

I appreciate your replay.


Xen-devel mailing list