From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj5p2-0000Ty-KX for qemu-devel@nongnu.org; Wed, 20 Nov 2013 06:19:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vj5ov-0001p3-5s for qemu-devel@nongnu.org; Wed, 20 Nov 2013 06:19:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj5ou-0001o6-S7 for qemu-devel@nongnu.org; Wed, 20 Nov 2013 06:19:45 -0500 Message-ID: <528C9AB3.905@redhat.com> Date: Wed, 20 Nov 2013 12:19:15 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <528C83C2.2040903@redhat.com> <20131120110000.GD20821@onelab2.iet.unipi.it> In-Reply-To: <20131120110000.GD20821@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] commit b1bbfe72 causes huge slowdown with no kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luigi Rizzo Cc: qemu-devel , Alex Bligh Il 20/11/2013 12:00, Luigi Rizzo ha scritto: > > WITHOUT THE PATCH, booting becomes slow as soon as the timer tick starts > and we load dummynet (which also starts a kernel thread every millisecond). > You should be able to see how the printing of kernel messages slows down > terribly around this point: > > ... > Timecounters tick every 1.000 msec > ipfw2 initialized, divert loadable, nat loadable, default to accept, logging disabled > DUMMYNET 0 with IPv6 initialized (100409) > .... > > and then it takes a long/varible time to reach the login prompt, > easily a couple of minutes or more. > If you start pkt-gen now, you should see a much lower rate, > around 300-500Kpps > > > > Since the problem seems timer-related, it makes sense that you are > not seeing much difference in linux which is probably tickless, > and that the trouble comes out on FreeBSD after the timers are > initialized. Saw it now with your FreeBSD guest. > But again I have no idea if my patch (which simply reverts part of > the offending commit) makes sense. No, the patch is wrong. :( Before Alex's patch, setting a timer did a timer_settime system call. After, setting the timer exits QEMU's event loop (which uses poll) and reenters it with a new deadline. This wouldn't be a problem; the difference is between one system call (timer_settime and a signal delivery (SIGALRM) before the patch, and two system calls afterwards (write to a pipe or eventfd + calling poll again when re-entering the event loop). Unfortunately, the exit/enter causes the main loop to grab the iothread lock, which in turns kicks the VCPU thread out of execution. The problem happens with "-smp 2" because FreeBSD uses a "pause" instruction in its idle loop, and QEMU does not implement it. Thus a lot of time is wasted running the second, idle VCPU rather than the first. The fix could be to implement the pause instruction. Paolo Paolo