From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MruNs-0004bR-Su for qemu-devel@nongnu.org; Sun, 27 Sep 2009 10:05:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MruNo-0004aG-Cr for qemu-devel@nongnu.org; Sun, 27 Sep 2009 10:05:52 -0400 Received: from [199.232.76.173] (port=34972 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MruNo-0004aD-7l for qemu-devel@nongnu.org; Sun, 27 Sep 2009 10:05:48 -0400 Received: from mail-yx0-f173.google.com ([209.85.210.173]:53657) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MruNn-0008JJ-PC for qemu-devel@nongnu.org; Sun, 27 Sep 2009 10:05:47 -0400 Received: by yxe3 with SMTP id 3so1841642yxe.4 for ; Sun, 27 Sep 2009 07:05:47 -0700 (PDT) Message-ID: <4ABF7137.1040502@codemonkey.ws> Date: Sun, 27 Sep 2009 09:05:43 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Main loop References: <4ABEB6B3.4010102@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Glauber Costa , qemu-devel@nongnu.org malc wrote: > On Sat, 26 Sep 2009, Anthony Liguori wrote: > > >> malc wrote: >> >>> At http://repo.or.cz/w/qemu/malc.git?a=shortlog;h=refs/heads/mtloop you >>> can find the branch which refactors main execution loop somewhat, effects >>> include: >>> >>> a. Host alarm timers are gone >>> b. IO thread is replaced (now Windows is supported too) >>> >>> >> What was the motivation? >> > > To have working audio on my 250 Hz system, where audio polling mode > ensures that wakeups happen at ~1Khz (with sufficiently small fragment > size) thus allowing Fast Tracker 2 to run properly. IOW this approach > allows to react to FD activity indpendantly of any timers. > Ah, yes. This is also addressed by the IO thread FWIW. The IO thread can run select without holding a mutex and can send a signal to the TCG thread in order to break it's execution out before attempting to acquire the global mutex. > Things i forgot to mention, slirp crawls (i.e. when sending some file > with nc to the guest the (hidden[1]) cpu utilization is only at ~50% > and subsequently it takes (relative to alarm mode) forever for transfer > to finnish, FWIW same problem plagues IO Thread) > The slirp issue is that it has a hook in the polling loop. The IO thread doesn't suffer from this problem because slirp is driven in the IO thread itself which still receives regular signals. FWIW, I consider the fact that slirp (or anything else) requires periodic polling to be a bug. > This is the 5 or 6th internal iteration of the thing, at one point i had > a system working where tcg only held the locks during the IO/helpers, but > in the end complexity wasn't worth it. > Glauber spent some time with the IO thread recently. Any reason you didn't start with the existing IO thread (besides the fact that it doesn't work with TCG)? Regards, Anthony Liguori