From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GjGvX-000299-MT for qemu-devel@nongnu.org; Sun, 12 Nov 2006 10:07:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GjGvV-00028c-Rc for qemu-devel@nongnu.org; Sun, 12 Nov 2006 10:07:19 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GjGvV-00028Z-Ms for qemu-devel@nongnu.org; Sun, 12 Nov 2006 10:07:17 -0500 Received: from [66.93.172.17] (helo=nevyn.them.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GjGvV-0007uw-AR for qemu-devel@nongnu.org; Sun, 12 Nov 2006 10:07:17 -0500 Date: Sun, 12 Nov 2006 10:07:15 -0500 From: Daniel Jacobowitz Subject: Re: [Qemu-devel] [PATCH] Huge TLB performance improvement Message-ID: <20061112150714.GA10651@nevyn.them.org> 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 On Sun, Nov 12, 2006 at 02:44:46PM +0000, 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. The brutal performance problem that Thiemo and I have been working on is for single page flushes. With that solved, though, there's still rather more memory management overhead than I'd like. I was also thinking about pretending there were more TLB entries than there actually are. We have a certain leeway to do this, because there are two tlb write instructions: indexed and random. So there's a while where the OS can't say for sure that an entry has been evicted. That might cut down on flushes, or it might not. My hope would be holding on to the evicted items until a global flush. But what Thiemo is getting at, I think, is that we have to flush qemu's TLB at every ASID switch. That's pretty lousy! It makes the ASID a net performance penalty, instead of a boost. I don't see anything obvious that I could do about it, though. The qemu tlb table only has room for is_user and the virtual address. > 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. Let me see if this makes any difference. -- Daniel Jacobowitz CodeSourcery