Re: Re: [Xen-devel] strange CPU utilization, could related to creditschedule ?

["kim.jin" <kim.jin@stromasys.com>]

[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

Then, how about the frequency of CPU? e.g., one VM have 1GHz CPUs, but the other have 2GHz CPUs. 

------------------				 
Best Regards!
 
Kim King
2011-01-17

-------------------------------------------------------------
George Dunlap
2011-01-17 18:41:35
MaoXiaoyun
xen devel
Re: [Xen-devel] strange CPU utilization, could related to creditschedule ?

>On Mon, Jan 17, 2011 at 3:52 AM, MaoXiaoyun <tinnycloud@hotmail.com> 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
>> priority CSCHED_PRI_TS_BOOST
>> 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
>200ms.
>
>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. :-)
>
> -George
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>.

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel