From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mruuk-0002nf-8m for qemu-devel@nongnu.org; Sun, 27 Sep 2009 10:39:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mruui-0002nT-Ss for qemu-devel@nongnu.org; Sun, 27 Sep 2009 10:39:49 -0400 Received: from [199.232.76.173] (port=39467 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mruui-0002nQ-Na for qemu-devel@nongnu.org; Sun, 27 Sep 2009 10:39:48 -0400 Received: from fe01x03-cgp.akado.ru ([77.232.31.164]:65391 helo=akado.ru) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mruui-0003tv-8C for qemu-devel@nongnu.org; Sun, 27 Sep 2009 10:39:48 -0400 Date: Sun, 27 Sep 2009 18:39:46 +0400 (MSD) From: malc Subject: Re: [Qemu-devel] Main loop In-Reply-To: <4ABF7137.1040502@codemonkey.ws> Message-ID: References: <4ABEB6B3.4010102@codemonkey.ws> <4ABF7137.1040502@codemonkey.ws> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Glauber Costa , qemu-devel@nongnu.org On Sun, 27 Sep 2009, Anthony Liguori wrote: > 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. Huh? I said the same issue _applies_ to IO Thread, you are contradicting it, how come? > > > 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)? > Because i wasn't writing a replacement for IO Thread to begin with (btw it does work with TCG), what it doesn't do is play nicely with icount[1], work on Windows, and for mysterious reasons still requires alarm timers, it also deadlocks for me when killing QEMU windows while running smp guest, but that's easily corrected mistake somewhere i guess. [1] Current mtloop has an issue with icount also, halt related. -- mailto:av1474@comtv.ru