From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GjDoM-0003gb-Ga for qemu-devel@nongnu.org; Sun, 12 Nov 2006 06:47:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GjDoG-0003Yt-VN for qemu-devel@nongnu.org; Sun, 12 Nov 2006 06:47:41 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GjDoG-0003YW-Mx for qemu-devel@nongnu.org; Sun, 12 Nov 2006 06:47:36 -0500 Received: from [193.252.22.23] (helo=smtp-msa-out08.orange.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GjDoG-00082W-Bd for qemu-devel@nongnu.org; Sun, 12 Nov 2006 06:47:36 -0500 Received: from [192.168.0.2] (ANice-251-1-39-161.w86-206.abo.wanadoo.fr [86.206.22.161]) by mwinf0804.orange.fr (SMTP Server) with ESMTP id 33F831C003D9 for ; Sun, 12 Nov 2006 12:47:32 +0100 (CET) Message-ID: <45570A32.3030608@wanadoo.fr> Date: Sun, 12 Nov 2006 12:49:06 +0100 From: Laurent Desnogues MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Huge TLB performance improvement References: <20060306145929.GD27785@networkno.de> <20061105153820.GB22548@nevyn.them.org> <20061112011035.GB21771@nevyn.them.org> In-Reply-To: <20061112011035.GB21771@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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 Daniel Jacobowitz a =E9crit : >=20 > 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). >=20 > Thiemo's patch, which flushes the whole jump buffer, cuts it to 1:40. >=20 > A patch which finds the entries which need to be flushed more > efficiently cuts it to 1:21. >=20 > 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. Laurent