From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49907 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNq3t-0006SB-Tt for qemu-devel@nongnu.org; Wed, 01 Dec 2010 12:01:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNq3s-0005ov-FA for qemu-devel@nongnu.org; Wed, 01 Dec 2010 12:01:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNq3s-0005of-5C for qemu-devel@nongnu.org; Wed, 01 Dec 2010 12:01:44 -0500 Message-ID: <4CF67F6F.2000102@redhat.com> Date: Wed, 01 Dec 2010 19:01:35 +0200 From: Avi Kivity MIME-Version: 1.0 References: <411b3f89b6b79b429686bd1b1fa188ba55b6c6f7.1290552026.git.quintela@redhat.com> <4CF45DE0.8020701@codemonkey.ws> <4CF65FBB.3020406@redhat.com> <4CF66FEB.7030602@codemonkey.ws> <4CF678E0.9070904@codemonkey.ws> <4CF67B19.9000308@redhat.com> <4CF67C9C.5000403@codemonkey.ws> <4CF67D65.8040408@redhat.com> <4CF67E35.2060505@codemonkey.ws> In-Reply-To: <4CF67E35.2060505@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 10/10] Maintaing number of dirty pages List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Juan Quintela On 12/01/2010 06:56 PM, Anthony Liguori wrote: > On 12/01/2010 10:52 AM, Avi Kivity wrote: >> On 12/01/2010 06:49 PM, Anthony Liguori wrote: >>>> We need actual measurements instead of speculations. >>> >>> >>> Yes, I agree 100%. I think the place to start is what I suggested >>> in a previous note in this thread, we need to measure actual stall >>> time in the guest. >> >> I'd actually start at the host. How much time does >> ioctl(KVM_GET_DIRTY_LOG) take? What's the percentage of time >> qemu_mutex is held? > > The question is, what really are the symptoms of the problem. It's > not necessarily a bad thing if KVM_GET_DIRTY_LOG takes a long while > qemu_mutex is held. Whether or not qemu_mutex is held, long KVM_GET_DIRTY_LONG runtimes are bad, since they are a lower bound on your downtime. And KVM_GET_DIRTY_LOG does a lot of work, and invokes synchronize_srcu_expedited(), which can be very slow. > > Is the problem that the monitor responds slowly? Is the problem that > the guest isn't consistently getting execution time? Is the proper > simply that the guest isn't getting enough total execution time? All three can happen if qemu_mutex is held too long. The third can happen for other reasons (like KVM_GET_DIRTY_LOG holding the mmu spinlock for too long, can fix with O(1) write protection). > > I think we need to identify exactly what the problem is before we look > for sources. > -- error compiling committee.c: too many arguments to function