From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsQ6R-0007zH-SW for qemu-devel@nongnu.org; Mon, 28 Sep 2009 19:57:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsQ6P-0007z5-Uw for qemu-devel@nongnu.org; Mon, 28 Sep 2009 19:57:58 -0400 Received: from [199.232.76.173] (port=51127 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsQ6P-0007z2-Pf for qemu-devel@nongnu.org; Mon, 28 Sep 2009 19:57:57 -0400 Received: from fe01x03-cgp.akado.ru ([77.232.31.164]:58666 helo=akado.ru) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsQ6O-00028d-Qa for qemu-devel@nongnu.org; Mon, 28 Sep 2009 19:57:57 -0400 Date: Tue, 29 Sep 2009 03:57:58 +0400 (MSD) From: malc Subject: Re: [Qemu-devel] Main loop In-Reply-To: <20090928135723.GK29735@mothafucka.localdomain> Message-ID: References: <4ABEB6B3.4010102@codemonkey.ws> <4ABF7137.1040502@codemonkey.ws> <20090928135723.GK29735@mothafucka.localdomain> 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: Glauber Costa Cc: qemu-devel@nongnu.org On Mon, 28 Sep 2009, Glauber Costa wrote: > > > 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. > [..snip..] > > Note that I don't think it requires alarm timers at all, by design. So, > again, why should we drop what we have in favour of your implementation? It doesn't require them, yet no one has come up even with the following crude patch which brings the time of booting debian netinst closer to mtloop. That said the real reason why iothread should be dropped is that it's basically a big pile of shit, not only alarm timers weren't dropped the code uses pthread_cond_timedwait all over the place for NO good reason without ever checking the result thus wasting time, 2 seconds of the boot time were chopped of just by replacing it with palin wait, with such an attention to detail i wonder what other monsters are lurking there. diff --git a/vl.c b/vl.c index c6c6a6b..fb04b25 100644 --- a/vl.c +++ b/vl.c @@ -718,6 +718,14 @@ static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t) static struct qemu_alarm_timer *alarm_timer; +static int notimer_start_timer(struct qemu_alarm_timer *t) +{ + return 0; +} +static void notimer_stop_timer(struct qemu_alarm_timer *t) +{ +} + #ifdef _WIN32 struct qemu_alarm_win32 { @@ -816,6 +824,9 @@ static void init_icount_adjust(void) } static struct qemu_alarm_timer alarm_timers[] = { +#ifdef CONFIG_IOTHREAD + {"notimer", 0, notimer_start_timer, notimer_stop_timer, NULL, NULL}, +#endif #ifndef _WIN32 #ifdef __linux__ {"dynticks", ALARM_FLAG_DYNTICKS, dynticks_start_timer, @@ -1167,7 +1178,7 @@ static int64_t qemu_next_deadline(void) return delta; } -#if defined(__linux__) || defined(_WIN32) +#if defined(__linux__) || defined(_WIN32) || defined(CONFIG_IOTHREAD) static uint64_t qemu_next_deadline_dyntick(void) { int64_t delta; @@ -4199,7 +4210,11 @@ static int qemu_calculate_timeout(void) return timeout; #else /* CONFIG_IOTHREAD */ - return 1000; + if (alarm_timer->start == notimer_start_timer) { + return qemu_next_deadline_dyntick() / 1000; + } else { + return 1000; + } #endif } -- mailto:av1474@comtv.ru