From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GjGZn-0000wo-SS for qemu-devel@nongnu.org; Sun, 12 Nov 2006 09:44:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GjGZn-0000vo-28 for qemu-devel@nongnu.org; Sun, 12 Nov 2006 09:44:51 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GjGZm-0000vl-UH for qemu-devel@nongnu.org; Sun, 12 Nov 2006 09:44:50 -0500 Received: from [65.74.133.4] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GjGZm-0004nv-Bd for qemu-devel@nongnu.org; Sun, 12 Nov 2006 09:44:50 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Huge TLB performance improvement Date: Sun, 12 Nov 2006 14:44:46 +0000 References: <20060306145929.GD27785@networkno.de> <200611121408.09895.paul@codesourcery.com> <20061112142938.GC4040@networkno.de> In-Reply-To: <20061112142938.GC4040@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611121444.46898.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > > Other targets have a hardware managed TLB. On a hardware managed TLB the > > OS treats it as if it were infinite size, and invalidation only occurs > > when a OS changes the mappings. On a software managed TLB "flushes" are > > more likely to occur during normal operation as TLB slots are reused. > > The excessive flushing for mips happens because Qemu doesn't properly > model the hardware's ASID handling. Are you sure? IIUC changing the ASID causes a full qemu TLB flush. The code we're tweaking here is for single page flush. Actually that gives me an idea. When a TLB entry with a different ASID gets evicted we currently flush that page. This should be a no-op because we already did a full flush when the ASID changed. The other explanation is that the gest OS is manually doing a full TLB flush by manually evicting all the TLB entries. I'd hope that a sane guest OS would only do that as a last resort though. Paul