From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GjHIF-0003ww-Vs for qemu-devel@nongnu.org; Sun, 12 Nov 2006 10:30:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GjHID-0003vA-PZ for qemu-devel@nongnu.org; Sun, 12 Nov 2006 10:30:47 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GjHID-0003uy-JA for qemu-devel@nongnu.org; Sun, 12 Nov 2006 10:30:45 -0500 Received: from [193.7.176.60] (helo=mail.bawue.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GjHID-0002DP-Gm for qemu-devel@nongnu.org; Sun, 12 Nov 2006 10:30:45 -0500 Date: Sun, 12 Nov 2006 15:26:46 +0000 From: Thiemo Seufer Subject: Re: [Qemu-devel] [PATCH] Huge TLB performance improvement Message-ID: <20061112152646.GD4040@networkno.de> References: <20060306145929.GD27785@networkno.de> <200611121408.09895.paul@codesourcery.com> <20061112142938.GC4040@networkno.de> <200611121444.46898.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <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: Paul Brook Cc: qemu-devel@nongnu.org Paul Brook wrote: > > > 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. I referred with that comment to the general problem of emulating a MMU with ASIDs in the current qemu fremework. > 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. That's the way the MIPS MMU is supposed to work. > 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. Linux/MIPS does this only at a ASID wraparound, which doesn't happen that often. Thiemo