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: Thu, 7 Oct 2010 18:18:03 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, yhxu@xxxxxxxxx
Delivery-date: Thu, 07 Oct 2010 15:18:39 -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=qkFXY39OROBTG9nyfIjB7Bc85fjI7rJcUAYNhyUgG3A=; b=ofCoftn28InMs/wDxeyfwKXrmhmt2/Bhda2sADojiDA7N4S6Zf9cSTypdR2VOzzOrM lg43AzPct4GhnBuufUOc3+Hk3utadDub+/StO9l+yU0DyikAuc3CJo1ffn6gC4qD2kS8 Ccj5VPXivwqee71OdtZ+mZM/m8RuS6YMXChpU=
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=R8Cxw5bf+iAk0pTv/oA55S5IgjxF0EMkzzgyKet586hMKq5p4PU3hlGmfZgEGH9WbU x/R8rZ1u3hY98D8Npft72Pgf0p5pQlYXiv4ua3nbsqIHi9KQQbVQ5tiIo2/RW1b/d7jH sy9TiOL6je79SwHggd4lLL9QU0WFjJj+1JiFA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTi=r2MzCwwNbNDopBkoCWvQSc=jkeWUy8hxKYD3_@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> <AANLkTi=Oa0_=vXrr63eALBU2sQa3aLV0NiQHt8hPPvcw@xxxxxxxxxxxxxx> <AANLkTimYTbf5meNptCtuiKWfQGd_qSNCkbCNabfREc_0@xxxxxxxxxxxxxx> <AANLkTintdF5h0-YD6FxjX0dapfbQYdAcK2P-=wHXnBiC@xxxxxxxxxxxxxx> <AANLkTinCbnzLLtNpdQe0x387UeDcy3SzrmffZw1oQAJo@xxxxxxxxxxxxxx> <AANLkTi=r2MzCwwNbNDopBkoCWvQSc=jkeWUy8hxKYD3_@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> Your understanding of Xen is not correct.  In Xen, the VM itself will
> initiate blocking if there is nothing for it to do.  PV domains call
> SCHED_OP_block(), which will cause the VM to block until it is woken
> by an event channel; and HVM domains will execute the HLT instruction,
> which will cause the VM to block until it is woken by an interrupt.
> If you do a more complete trace (i.e., "xentrace -e all") and look at
> the results with xenalyze, you'll see dom2 making a sched_op
> hypercall, then transitioning from RUNSTATE_running to
> RUNSTATE_blocked.

I originally considered that when a Dom has an I/O event, its VCPU
would be waken up, in another word, csched_vcpu_wake(struct vcpu *vc)
should be invoked. However, I find I am definitely wrong. As long as
there is a CPU intensive program running in a Dom, this Dom should
never be in a state of "sleep"? In another word, it should never be
waken up?

In such case, suppose there is an I/O event for a VM, how can I insert
this VM schedule entity into the head of the link list and make
schedule() work immediately? I tried in the function of
csched_vcpu_wake, but since this VM also has CPU intensive program,
the throughput of I/O makes no difference.

I feel that in order to make VM that has I/O scheduled as soon as
possible(without considering CPU fairness), other files should be
modified besides csched_credit.c. But where it is?

I really appreciate your help.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>