qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Huge TLB performance improvement


From: Thiemo Seufer
Subject: Re: [Qemu-devel] [PATCH] Huge TLB performance improvement
Date: Sun, 12 Nov 2006 14:29:38 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

Paul Brook wrote:
> On Sunday 12 November 2006 11:49, Laurent Desnogues wrote:
> > Daniel Jacobowitz a écrit :
> > > Straight qemu with my previously posted MIPS patches takes 6:13 to
> > > start and reboot a MIPS userspace (through init, so lots of fork/exec).
> > >
> > > Thiemo's patch, which flushes the whole jump buffer, cuts it to 1:40.
> > >
> > > A patch which finds the entries which need to be flushed more
> > > efficiently cuts it to 1:21.
> > >
> > > A patch which flushes up to 1/32nd of the jump buffer indiscriminately
> > > cuts it to 1:11-1:13.
> >
> > Warning:  I don't know anything about the Qemu MMU implementation
> > so this question is perhaps stupid :)
> >
> > Did you try to benchmark some user space applications with the
> > various implementations you propose?  The boot of a Linux kernel
> > is quite heavy on various kinds of flushes and so is very
> > different from "standard" applications.
> 
> MIPS is different because it has a relatively small software managed TLB. 

JFTR, increasing the TLB size from 16 to 64 entries made no performance
difference whatsoever.

> 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.


Thiemo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]