From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flAGK-00067D-Vr for qemu-devel@nongnu.org; Thu, 02 Aug 2018 05:51:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1flAGF-0004lw-4l for qemu-devel@nongnu.org; Thu, 02 Aug 2018 05:51:17 -0400 Date: Thu, 2 Aug 2018 10:50:57 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20180802095056.GB2523@work-vm> References: <20180626135035.133432-5-vsementsov@virtuozzo.com> <700dffe4-f3a8-8f70-052c-9f6f8ffbe3d3@redhat.com> <20180801102031.GC2691@work-vm> <64aad02b-3d5c-70d6-0f5a-93dd5b88e4bc@redhat.com> <20180801174005.GD2691@work-vm> <20180801185515.GE2691@work-vm> <6bfdc952-fb17-feae-f367-be710853d829@openvz.org> <20180802092907.GA2523@work-vm> <202065a2-f9d1-ce31-b12b-437d57095ac1@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202065a2-f9d1-ce31-b12b-437d57095ac1@openvz.org> Subject: Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: John Snow , Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org, qemu-block@nongnu.org, quintela@redhat.com, stefanha@redhat.com, famz@redhat.com, mreitz@redhat.com, kwolf@redhat.com, Eric Blake * Denis V. Lunev (den@openvz.org) wrote: > > I don't quite understand the last two paragraphs. > we are thinking right now to eliminate delay on regular IO > for migration. There is some thoughts and internal work in > progress. That is why I am worrying. What downtime are you typicaly seeing and what are you aiming for? It would be good if you could explain what you're planning to fix there so we can get a feel for it nearer the start of it rather than at the end of the reviewing! Dave > > > However, coming back to my question; it was really saying that > > normal guest IO during the end of the migration will cause > > a delay; I'm expecting that to be fairly unrelated to the size > > of the disk; more to do with workload; so I guess in your case > > the worry is the case of big large disks giving big large > > bitmaps. > > exactly! > > Den -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK