diff options
author | Anthony Liguori <aliguori@us.ibm.com> | 2011-08-22 08:24:58 -0500 |
---|---|---|
committer | Anthony Liguori <aliguori@us.ibm.com> | 2011-09-02 10:34:55 -0500 |
commit | 12d4536f7d911b6d87a766ad7300482ea663cea2 (patch) | |
tree | 848fe9cb11b82145fae05ee05aace4f90a3564af /vl.c | |
parent | d9cd446b4f6ff464f9520898116534de988d9bc1 (diff) |
main: force enabling of I/O thread
Enabling the I/O thread by default seems like an important part of declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means that the
TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which
currently requires a (racey) signal based alarm system.
I know there have been concerns about performance. I think so far the ones that
have come up (virtio-net) are most likely due to secondary reasons like
decreased batching.
I think we ought to force enabling I/O thread early in 1.0 development and
commit to resolving any lingering issues.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'vl.c')
-rw-r--r-- | vl.c | 18 |
1 files changed, 0 insertions, 18 deletions
@@ -1445,17 +1445,6 @@ int main_loop_wait(int nonblocking) return ret; } -#ifndef CONFIG_IOTHREAD -static int vm_request_pending(void) -{ - return powerdown_requested || - reset_requested || - shutdown_requested || - debug_requested || - vmstop_requested; -} -#endif - qemu_irq qemu_system_powerdown; static void main_loop(void) @@ -1470,14 +1459,7 @@ static void main_loop(void) qemu_main_loop_start(); for (;;) { -#ifdef CONFIG_IOTHREAD nonblocking = !kvm_enabled() && last_io > 0; -#else - nonblocking = cpu_exec_all(); - if (vm_request_pending()) { - nonblocking = true; - } -#endif #ifdef CONFIG_PROFILER ti = profile_getclock(); #endif |