From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NhgVJ-00057A-H6 for qemu-devel@nongnu.org; Wed, 17 Feb 2010 04:47:33 -0500 Received: from [199.232.76.173] (port=44386 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NhgVI-00056h-Uz for qemu-devel@nongnu.org; Wed, 17 Feb 2010 04:47:33 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NhgVG-0007dm-7M for qemu-devel@nongnu.org; Wed, 17 Feb 2010 04:47:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45526) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NhgVF-0007de-Ql for qemu-devel@nongnu.org; Wed, 17 Feb 2010 04:47:30 -0500 Message-ID: <4B7BBB28.4090308@redhat.com> Date: Wed, 17 Feb 2010 11:47:20 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2] qemu-kvm: Speed up of the dirty-bitmap-traveling References: <4B728FF9.6010707@lab.ntt.co.jp> <4B72B28E.6010801@redhat.com> <4B72D706.3070602@codemonkey.ws> <4B74B70A.4030805@lab.ntt.co.jp> <4B77EDC2.7000401@redhat.com> <4B78E5C5.80802@lab.ntt.co.jp> <247526C9-7810-4F4D-AE3D-C1A774FF6FFB@suse.de> <4B7A7E72.6060305@lab.ntt.co.jp> <2AB041C1-C6BC-41DD-B574-308B994C2B2B@suse.de> <4B7BBA1D.2060703@lab.ntt.co.jp> In-Reply-To: <4B7BBA1D.2060703@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: OHMURA Kei Cc: "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , mtosatti@redhat.com, Yoshiaki Tamura , Alexander Graf , drepper@redhat.com On 02/17/2010 11:42 AM, OHMURA Kei wrote: >>>> "We think"? I mean - yes, I think so too. But have you actually >>>> measured it? >>>> How much improvement are we talking here? >>>> Is it still faster when a bswap is involved? >>> Thanks for pointing out. >>> I will post the data for x86 later. >>> However, I don't have a test environment to check the impact of bswap. >>> Would you please measure the run time between the following section >>> if possible? >> >> It'd make more sense to have a real stand alone test program, no? >> I can try to write one today, but I have some really nasty important >> bugs to fix first. > > > OK. I will prepare a test code with sample data. Since I found a ppc > machine around, I will run the code and post the results of > x86 and ppc. > I've applied the patch - I think the x86 results justify it, and I'll be very surprised if ppc doesn't show a similar gain. Skipping 7 memory accesses and 7 tests must be a win. -- error compiling committee.c: too many arguments to function