|
From: | Hans de Goede |
Subject: | Re: [Qemu-devel] [PATCH 06/22] ehci: Speed up the timer of raising int from the async schedule |
Date: | Wed, 17 Oct 2012 13:11:05 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121009 Thunderbird/16.0 |
Hi, On 10/17/2012 01:01 PM, Gerd Hoffmann wrote:
On 10/15/12 15:00, Hans de Goede wrote:Hi, On 10/15/2012 01:17 PM, Gerd Hoffmann wrote:On 10/15/12 12:38, Hans de Goede wrote:Often the guest will queue up new packets in response to a packet, in the async schedule with its IOC flag set, completing. By speeding up the frame-timer, we notice these new packets earlier. This increases the speed (MB/s) of a Linux guest reading from a USB mass storage device by a factor of 1.15 on top of the "Improve latency of interrupt delivery" speed-ups, both with and without input pipelining enabled.Why not just set async_stepdown to 0?We already do that whenever we run a package completion (it get sets when we move to the executing stage). What this patch does is request the frame timer to run again in 500 usecs instead of after 1 ms, thus making us see and process async transfers faster when they are queued up in response to just completed packages (which we've told the guest about with the int interrupt). This makes the USB-bus / device idle time between any 2 transfers of the 3 transfer involving USB storage BOT time shorter, thereby speeding things up.Don't feel like having two mechanisms for wakeup rate control. Can't we integrate this with async_stepdown? Changing the baseline maybe, so stepdown=0 doesn't mean 1000 Hz but 2000 Hz?
That is actually close to what I wanted to do at first (I wanted to use stepdown=-1 for the faster wakeup case). But there are 2 problems with this: 1) It causes migration issues when migrating to / from an old version 2) We don't want to change the wakeup rate when the interrupt flag gets set as pending, but when it actually gets committed, and we only want to change the wakeup rate when the int was requested by an async packet, not when it was requested by a periodic packet, so we will need the int_req_by_async flag anyways, as which point this seemed the cleanest way. Regards, Hans
[Prev in Thread] | Current Thread | [Next in Thread] |