From: Hans de Goede <hdego...@redhat.com>
I tried lowering the time between raising an interrupt and rescanning the
async schedule to see if the guest has queued a new transfer before, but
that did not have any positive effect. I now believe the cause for this is
that lowering this time made it more likely to hit the 1 ms interrupt
threshold penalty for the next packet, as described in my
"ehci: Use uframe precision for interrupt threshold checking" commit.
Now that we do interrupt threshold handling with uframe precision, futher
lowering this time from .5 to .25 ms gives an extra 15% improvement in speed
(MB/s) reading from a simple USB-2.0 thumb-drive.
While at it also properly set the int_req_by_async flag for short packet
completions.
Signed-off-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
---
hw/usb/hcd-ehci.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index efa1d77..8da4b6a 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -1347,6 +1347,9 @@ static void ehci_execute_complete(EHCIQueue *q)
if (tbytes) {
/* 4.15.1.2 must raise int on a short input packet */
ehci_raise_irq(q->ehci, USBSTS_INT);
+ if (q->async) {
+ q->ehci->int_req_by_async = true;
+ }
}
} else {
tbytes = 0;
@@ -2337,7 +2340,7 @@ static void ehci_frame_timer(void *opaque)
/* If we've raised int, we speed up the timer, so that we quickly
* notice any new packets queued up in response */
if (ehci->int_req_by_async && (ehci->usbsts & USBSTS_INT)) {
- expire_time = t_now + get_ticks_per_sec() / (FRAME_TIMER_FREQ * 2);
+ expire_time = t_now + get_ticks_per_sec() / (FRAME_TIMER_FREQ * 4);
ehci->int_req_by_async = false;
} else {
expire_time = t_now + (get_ticks_per_sec()
--
1.7.1
