From mboxrd@z Thu Jan 1 00:00:00 1970 From: alice wan Subject: qemu cpu utility too high as dom0 cpu stealtime's also high Date: Fri, 10 Jun 2011 21:57:13 +0800 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0813875852==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============0813875852== Content-Type: multipart/alternative; boundary=bcaec5215fed5589c504a55bf29f --bcaec5215fed5589c504a55bf29f Content-Type: text/plain; charset=ISO-8859-1 hi all, when i started 10 windows vms of 4 vcpu on the host with 8 cpu, dom0 has 4 shareble vcpu, i found qemu-dm cpu utility is too high, about 80-90%, lasting for more than half an hour. after a long period of time, the dom0 became normal. i observed that when qemu-dm %cpu's too high, the dom0 cpu's stealtime was also too high. when dom0 became normal, %st and qemu %cpu also became low. high stealtime is reasonable as the cpu is too busy, the time vcpu wait for cpu scheduling is too long. however, qemu high cpu utility is unreasonable, the oprofile report of qemu seems normal. I doubt the granularity of task cpu time accounting seems too rough. It seems that task cpu accounting didn't distinguish virtual cpu time from cpu time so that the qemu-dm cpu time = real cpu time+steal time Does the task cpu accounting is based on tick? the config about accounting 's like this: CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set Should i turn on the CONFIG_IRQ_TIME_ACCOUNTING ? Any advice is appreciated, thanks in advance. --bcaec5215fed5589c504a55bf29f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi all,
=A0
=A0=A0=A0=A0=A0=A0 when i started 10 windows vms of 4 vcpu on the host= with 8 cpu, dom0 has 4 shareble vcpu, i found qemu-dm cpu utility is too h= igh, about 80-90%, lasting for more than half an hour. after a long period = of time, the dom0 became normal.
=A0
=A0=A0=A0=A0=A0=A0=A0=A0i observed that when qemu-dm %cpu's too hi= gh, the dom0 cpu's stealtime was also too high.
=A0=A0=A0=A0=A0=A0=A0 when dom0 became normal, %st=A0 and qemu %cpu al= so=A0became low.
=A0
=A0=A0=A0=A0=A0=A0=A0 high stealtime is reasonable as the cpu is too b= usy, the time vcpu wait for cpu scheduling =A0is too long.
=A0
=A0=A0=A0=A0=A0=A0=A0 however, qemu high cpu utility is unreasonable,= =A0 the oprofile report of qemu seems normal.
=A0
=A0=A0=A0=A0=A0=A0=A0 I doubt the granularity of task cpu time account= ing=A0seems too rough.
=A0
=A0=A0=A0=A0=A0=A0=A0=A0It seems that task cpu accounting didn't d= istinguish virtual cpu time from cpu time so that =A0the qemu-dm cpu time = =3D real cpu time+steal time
=A0
=A0=A0=A0=A0=A0=A0=A0 Does the task cpu accounting is based on tick? <= /div>
=A0
=A0=A0=A0=A0=A0=A0=A0=A0the config about accounting 's like this:<= /div>
=A0=A0=A0=A0=A0=A0=A0 CONFIG_TASK_IO_ACCOUNTING=3Dy
=A0=A0=A0=A0=A0= =A0=A0 # CONFIG_IRQ_TIME_ACCOUNTING is not set
=A0
=A0=A0=A0=A0=A0=A0=A0 Should i turn on the CONFIG_IRQ_TIME_ACCOUNTING = ?
=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0Any advice is appreciated, thanks in advance.<= /div> --bcaec5215fed5589c504a55bf29f-- --===============0813875852== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0813875852==--