From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTDoh-0000mR-UR for qemu-devel@nongnu.org; Tue, 30 Oct 2012 11:33:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTDob-00010G-2u for qemu-devel@nongnu.org; Tue, 30 Oct 2012 11:33:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTDoa-000102-RG for qemu-devel@nongnu.org; Tue, 30 Oct 2012 11:33:17 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9UFXFCa031532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 30 Oct 2012 11:33:15 -0400 From: Juan Quintela In-Reply-To: <508FA8C5.9070502@redhat.com> (Orit Wasserman's message of "Tue, 30 Oct 2012 12:15:33 +0200") References: <1350545426-23172-1-git-send-email-quintela@redhat.com> <1350545426-23172-31-git-send-email-quintela@redhat.com> <5083F245.5020903@redhat.com> <87r4olxy0o.fsf@elfo.mitica> <508CEE69.1060203@redhat.com> <508FA8C5.9070502@redhat.com> Date: Tue, 30 Oct 2012 16:33:11 +0100 Message-ID: <87a9v4ht54.fsf@elfo.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 30/30] ram: optimize migration bitmap walking Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Orit Wasserman Cc: qemu-devel@nongnu.org Orit Wasserman wrote: >> If we are in iterate state this means the bitmap is changing all the time, >> even when we didn't finish a complete cycle (for example we get to >> the bandwidth limit, exit ram_save_iterate and sync the bitmap in >> pending). >> This means that bits in part of the bitmap we already walked can get >> dirty again. >> In that case the if condition can be true for a dirty bit, >> in the current code we reset it and than break for the loop, this >> means it is set clean without sending it, which is a problem. >> Changing the line order will fix it (the way it was before). >> > OK read the code more thoroughly, there is no way that the bitmap will > if we do a full cycle in ram_save_block, > We can actually simplify and the function by checking the number of > dirty pages. If it is zero we can return > immediately. > If it is not zero it means we will exit the loop when we will find the > dirty page. Very good idea. Thanks. Later, Juan.