| commit | 33ca1c27b011a5b55c219d8d972b7d5ad9075708 | |
| author | Mark McLoughlin <markmc@redhat.com> | |
| Mon, 11 Aug 2008 20:12:15 +0000 (11 21:12 +0100) | ||
| committer | Avi Kivity <avi@qumranet.com> | |
| Wed, 13 Aug 2008 09:12:19 +0000 (13 12:12 +0300) | ||
| tree | 7d38eded5baa28ff32ba7718eec8fbae07c60bb1 | treesnapshot (tar.gz zip) |
| parent | 0d1c0341d94c52f065ac6ac78b313eb21ade6525 | commitdiff |
Drop the mutex while reading from tapfd
The idea here is that with GSO, packets are much larger
and we can allow the vcpu threads to e.g. process irq
acks during the window where we're reading these
packets from the tapfd.
One known issue with this is that it triggers a subtle
SMP race in the kernel's posix-timers and signalfd code.
See here for more details and a test case:
http://lkml.org/lkml/2008/7/17/151
The symptoms of this are that:
a) occassionally throughput drops almost to zero
b) manually doing "killall -ALRM qemu-kvm" kicks qemu
out if its funk.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Avi Kivity <avi@qumranet.com>
The idea here is that with GSO, packets are much larger
and we can allow the vcpu threads to e.g. process irq
acks during the window where we're reading these
packets from the tapfd.
One known issue with this is that it triggers a subtle
SMP race in the kernel's posix-timers and signalfd code.
See here for more details and a test case:
http://lkml.org/lkml/2008/7/17/151
The symptoms of this are that:
a) occassionally throughput drops almost to zero
b) manually doing "killall -ALRM qemu-kvm" kicks qemu
out if its funk.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Avi Kivity <avi@qumranet.com>
| vl.c | diffblobblamehistory |