From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TORNr-0008Kc-4c for qemu-devel@nongnu.org; Wed, 17 Oct 2012 07:01:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TORNl-0005zO-7T for qemu-devel@nongnu.org; Wed, 17 Oct 2012 07:01:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TORNk-0005zG-Vp for qemu-devel@nongnu.org; Wed, 17 Oct 2012 07:01:49 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9HB1l4s006673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Oct 2012 07:01:48 -0400 Message-ID: <507E9014.7010507@redhat.com> Date: Wed, 17 Oct 2012 13:01:40 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1350297511-25437-1-git-send-email-hdegoede@redhat.com> <1350297511-25437-7-git-send-email-hdegoede@redhat.com> <507BF0C6.9010300@redhat.com> <507C08D1.9070607@redhat.com> In-Reply-To: <507C08D1.9070607@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 06/22] ehci: Speed up the timer of raising int from the async schedule List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: qemu-devel@nongnu.org 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? cheers, Gerd