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] strange CPU utilization, could related to credit schedul

To: MaoXiaoyun <tinnycloud@xxxxxxxxxxx>
Subject: Re: [Xen-devel] strange CPU utilization, could related to credit schedule ?
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Mon, 17 Jan 2011 10:41:04 +0000
Cc: xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 17 Jan 2011 02:41:46 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D7OsZyyC8OTiU3Ti2lNHmyb6vV1ln/Sk6EKYmamHoVY=; b=Cm5B8cKTjIyaw0k1JaK+JEIQ0HltNm7sfZp+23R/UtfX5Yd/Lpq0qMXPHqa/zFxTi4 FcNjJDO/ZQd7sE7B8RclYox1sQfY6+KsdsnbqPyU3Jozc9K+oRAUGtyLBb+bqJX/Y4+h NSkBYFqNuOEta8eLeBSsH475mfTQhkLN9VYp8=
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=Ck7qixWvM3FDG52DBDNz0/vlVqNWmNN2kdsXbLa6dQz0LNF3Nfgm0Cr6Hpl4/X4qAU ZvgwRdYUcj/ML89RvHGpVegI4Eb21tBMhVK2ht3Cd/3KDSpVqZDmAqk8qVERW7pSsFYW 1RloqIPnOGyq2LdIWaLD6Eh5QrNidBU5E82kk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BLU157-w377DD793B20486EA30DE66DAF40@xxxxxxx>
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: <SNT0-MC3-F148nSuKiM000aac29@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <BLU157-ds6B75FFC7D37D79C68C5B4DA3C0@xxxxxxx> <AANLkTi=zHP5fQLtHN5xva0e8FSVistd8Se8Ys2nrqh=t@xxxxxxxxxxxxxx> <BLU157-ds19D073F9CDA3C196544C34DA240@xxxxxxx> <4CF38C2F.3020605@xxxxxxxxxxxxx> <BLU0-SMTP109390F576549178294AEC6DA240@xxxxxxx> <4CF4D70D.8030500@xxxxxxxxxxxxx> <BLU157-ds165D388AAAFBCDDF05B65DA260@xxxxxxx> <BLU157-ds148DA879968C9AA934F810DAF10@xxxxxxx> <AANLkTi=O3W-fr28_LepZJPQ323hCH8qU7Byc-w-Jt0pu@xxxxxxxxxxxxxx> <BLU157-w5926774C84AF85B31D36ADAF00@xxxxxxx> <BLU157-w377DD793B20486EA30DE66DAF40@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, Jan 17, 2011 at 3:52 AM, MaoXiaoyun <tinnycloud@xxxxxxxxxxx> wrote:
> Hi George:
>        1.  From the algorithm, since domains credits is  direct proportion
> to its weight,
> I think if there are two cpu-bound domains with same weight, no matter how
> many
> vcpus they have, they will have the same CPU times accmulated, right?

It used to be the case, yes.  But since that is very
counter-intuitive, some months ago I introduced a change such that the
weight is calculated on a per-vcpu basis.  If you look in
csched_acct(), when accounting credit, weight of a domain is
multiplied by sdom->active_vcpu_count.

>        2. if 1 is true, what the different between domains with same
> weight but have
> different VCPUS(say one has 4 vcpus, another has 8)?

If two domains have the same number of "active" vcpus (4 each, for
example) they'll get the same amount of CPU time.  But if the 8-vcpu
domain has 8 vcpus in "active" mode, it will get twice as much time.

But this is a recent change; in earlier versions of Xen (before 3.4
for sure, and possibly 4.0, I can't remember), if two VMs are given
the same weight, they'll get the same cpu time.

>        3. I am fully understand the problems of "credit 1 schedule "in your
> ppt of "Xenschedulerstatus"
> (1)Client hypervisors and audio/video 
>     Audio VM: 5% CPU
>  2x Kernel-build VMs: 97% cpu
>  30-40 audio skips over 5 minutes
> Do you mean "kernel-build VMs" has great impact on "Audio VM", and does
> solve this?

BOOST does not solve this problem.  I think I described the problem in
the paper: BOOST is an unstable place to be -- you can't stay there
very long.  The way BOOST works is this:
* You are put into BOOST if your credits reach a certain threshold
(30ms worth of credit)
* You are taken out of BOOST if you are interrupted by a scheduler "tick"

If you run at about 5% (or about 1/20 of the time), you can expect to
be running on average every 20 ticks.  Since timer ticks happen every
10ms, that means you can expect to stay in BOOST for an average of

So no matter how little cpu you use, you'll flip back and forth
between BOOST and normal, often several times per second.

> many many thanks, those confusions really makes me headache, I am a bit of
> silly.

不是! 懂scheduling非常难.  It probably took me about six months to really
understand what was going on. :-)


Xen-devel mailing list