From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: [PATCH 3 of 5] rombios/ata: Reading this status register has no relevant side effects Date: Mon, 30 Jul 2012 22:57:31 +0100 Message-ID: <20120730225731.70f6842a@ultron> References: <5e8fbfea222946369f08.1343677642@andrewcoop.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5e8fbfea222946369f08.1343677642@andrewcoop.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Keir Fraser , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Mon, 30 Jul 2012 20:47:22 +0100 Andrew Cooper wrote: > So taking two traps when one will do is pointless. This codepath is on the int > 0x13 hot path, and removing it has about a 30% reduction in the number of traps > to Qemu during Win7 boot. You can't read the status for 400nS after a command issue, so throwing one away is a typical way to handle that. All of this is optimising the wrong thing. The problem is that neither kvm not xen have the most basic prediction handlers in the kernel side exception code so keep hitting qemu. For a 99% of the ATA transfers you can predict the next few in and outs and pre-load them into your trap handler avoiding bouncing into qemu, on a miss you go back into qemu and load the next prediction block (or tree even) That's the kind of optimisation that will really make it fly. Alan