| commit | 12d4536f7d911b6d87a766ad7300482ea663cea2 | |
| author | Anthony Liguori <aliguori@us.ibm.com> | |
| Mon, 22 Aug 2011 13:24:58 +0000 (22 08:24 -0500) | ||
| committer | Anthony Liguori <aliguori@us.ibm.com> | |
| Fri, 2 Sep 2011 15:34:55 +0000 (2 10:34 -0500) | ||
| tree | 848fe9cb11b82145fae05ee05aace4f90a3564af | treesnapshot (tar.gz zip) |
| parent | d9cd446b4f6ff464f9520898116534de988d9bc1 | commitdiff |
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>
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>
| configure | diffblobblamehistory | |
| cpus.c | diffblobblamehistory | |
| hw/qxl.c | diffblobblamehistory | |
| kvm-all.c | diffblobblamehistory | |
| qemu-timer.c | diffblobblamehistory | |
| vl.c | diffblobblamehistory |