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 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
