From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBewJ-0004N3-6J for qemu-devel@nongnu.org; Sat, 02 Mar 2013 00:24:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBewG-0001gt-PB for qemu-devel@nongnu.org; Sat, 02 Mar 2013 00:24:55 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]:43553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBewG-0001eF-Ia for qemu-devel@nongnu.org; Sat, 02 Mar 2013 00:24:52 -0500 Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 1 Mar 2013 22:24:48 -0700 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 9927619D8036 for ; Fri, 1 Mar 2013 22:24:42 -0700 (MST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r225Oixn182768 for ; Fri, 1 Mar 2013 22:24:44 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r225RGW6010726 for ; Fri, 1 Mar 2013 22:27:16 -0700 Message-ID: <51318D1B.4010406@linux.vnet.ibm.com> Date: Sat, 02 Mar 2013 00:24:43 -0500 From: "Michael R. Hines" MIME-Version: 1.0 References: <512FE6C3.5030409@linux.vnet.ibm.com> <51307618.6010708@redhat.com> In-Reply-To: <51307618.6010708@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] parallelize migration_bitmap_sync() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , "qemu-devel@nongnu.org" , quintela@redhat.com Juan, Can I try this patch that Paolo mentioned? Does it go directly from GET_LOG_DIRTY => migration_bitmap? Or is there still an intermediate sync in your patch? Thanks, - Michael On 03/01/2013 04:34 AM, Paolo Bonzini wrote: > Il 01/03/2013 00:22, Michael R. Hines ha scritto:te >> Hi, >> >> Currently migration_bitmap_sync() is very expensive: on the order of >> 15-20 milliseconds by my count using timestamps (for a simple 2GB ram >> virtual machine). >> Until new EPT processor versions come out in 2014, we need software >> support for cutting this time down much lower........by at least an >> order of magnitude. >> >> Would anyone be opposed to me writing a patch that creates N threads and >> dividing up the migration_bitmap_sync() function to have the dirty page >> scanning run in parallel? > Yes, that's a possibility. You can make a quick prototype using OpenMP. > > But Juan is working on making the dirty bitmap really a bitmap (not a > "bytemap"). That should speed up migration_bitmap_sync by a factor of > 64 (i.e. sizeof(long)*8). > > Paolo >