summaryrefslogtreecommitdiff
path: root/kvm-all.c
diff options
context:
space:
mode:
authorAnthony Liguori <aliguori@us.ibm.com>2011-08-22 08:24:58 -0500
committerAnthony Liguori <aliguori@us.ibm.com>2011-09-02 10:34:55 -0500
commit12d4536f7d911b6d87a766ad7300482ea663cea2 (patch)
tree848fe9cb11b82145fae05ee05aace4f90a3564af /kvm-all.c
parentd9cd446b4f6ff464f9520898116534de988d9bc1 (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 'kvm-all.c')
-rw-r--r--kvm-all.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/kvm-all.c b/kvm-all.c
index 0ae2e2697e..fbb9ff3bef 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -479,7 +479,7 @@ static int kvm_check_many_ioeventfds(void)
* Older kernels have a 6 device limit on the KVM io bus. Find out so we
* can avoid creating too many ioeventfds.
*/
-#if defined(CONFIG_EVENTFD) && defined(CONFIG_IOTHREAD)
+#if defined(CONFIG_EVENTFD)
int ioeventfds[7];
int i, ret = 0;
for (i = 0; i < ARRAY_SIZE(ioeventfds); i++) {