From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FbMmA-0005bt-K6 for qemu-devel@nongnu.org; Wed, 03 May 2006 15:12:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FbMm8-0005Zx-NA for qemu-devel@nongnu.org; Wed, 03 May 2006 15:12:41 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FbMm8-0005Zs-H4 for qemu-devel@nongnu.org; Wed, 03 May 2006 15:12:40 -0400 Received: from [84.96.92.61] (helo=sMtp.neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FbMmZ-0004zJ-NJ for qemu-devel@nongnu.org; Wed, 03 May 2006 15:13:07 -0400 Received: from [84.102.211.51] by sp604002mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0IYP00GL0EOU6GB0@sp604002mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Wed, 03 May 2006 21:12:31 +0200 (CEST) Date: Wed, 03 May 2006 21:11:48 +0200 From: Fabrice Bellard Subject: Re: [Qemu-devel] qemu/hw mips_r4k.c In-reply-to: <20060502232924.GJ5004@networkno.de> Message-id: <44590074.90303@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <20060502232924.GJ5004@networkno.de> 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 Thiemo Seufer wrote: > Fabrice Bellard wrote: > >>CVSROOT: /sources/qemu >>Module name: qemu >>Branch: >>Changes by: Fabrice Bellard 06/05/02 22:18:28 >> >>Modified files: >> hw : mips_r4k.c >> >>Log message: >> performance boost (on P4 hosts at least, rdtsc is a _very_ bad random generator) >> >>CVSWeb URLs: >>http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.15&tr2=1.16&r1=text&r2=text > > > Does this really provide a measurable performance improvement? > Real hardware simply increments cp0_random together with the cycle > counter, this is randomized enough for TLB entry replacement. Unfortunately, at least on my P4 PC it is not random enough: it is always a multiple of two, so the number of TLBs is divided by two ! The speed improvement is _very_ noticeable. Your patch to accelerate tlb_flush_page() is still interesting, but I would like to be sure that it does not reduce the speed of the x86 target. In particular, it could be possible to make it even faster by reducing the size of the memset by using a smarter hash for tb_jmp_cache (a few bit of the index could depend only on the memory page number). Fabrice.