From patchwork Tue Jul 24 18:36:25 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Juan Quintela X-Patchwork-Id: 173003 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 77C822C007D for ; Wed, 25 Jul 2012 04:37:18 +1000 (EST) Received: from localhost ([::1]:57831 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Stjyu-0007dZ-FC for incoming@patchwork.ozlabs.org; Tue, 24 Jul 2012 14:37:16 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Stjya-0007bb-SP for qemu-devel@nongnu.org; Tue, 24 Jul 2012 14:37:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1StjyZ-0005Tq-EP for qemu-devel@nongnu.org; Tue, 24 Jul 2012 14:36:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1StjyZ-0005Tm-6a for qemu-devel@nongnu.org; Tue, 24 Jul 2012 14:36:55 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6OIasPT021997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jul 2012 14:36:54 -0400 Received: from trasno.mitica (ovpn-116-53.ams2.redhat.com [10.36.116.53]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6OIaqYS003393; Tue, 24 Jul 2012 14:36:53 -0400 From: Juan Quintela To: qemu-devel@nongnu.org Date: Tue, 24 Jul 2012 20:36:25 +0200 Message-Id: <1343155012-26316-1-git-send-email-quintela@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [RFC 00/27] Migration thread (WIP) X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Hi This series are on top of the migration-next-v5 series just posted. First of all, this is an RFC/Work in progress. Just a lot of people asked for it, and I would like review of the design. It does: - get a new bitmap for migration, and that bitmap uses 1 bit by page - it unfolds migration_buffered_file. Only one user existed. - it simplifies buffered_file a lot. - About the migration thread, special attention was giving to try to get the series review-able (reviewers would tell if I got it). Basic design: - we create a new thread instead of a timer function - we move all the migration work to that thread (but run everything except the waits with the iothread lock. - we move all the writting to outside the iothread lock. i.e. we walk the state with the iothread hold, and copy everything to one buffer. then we write that buffer to the sockets outside the iothread lock. - once here, we move to writting synchronously to the sockets. - this allows us to simplify quite a lot. And basically, that is it. Notice that we still do the iterate page walking with the iothread held. Light testing show that we got similar speed and latencies than without the thread (notice that almost no optimizations done here yet). Appart of the review: - Are there any locking issues that I have missed (I guess so) - stop all cpus correctly. vm_stop should be called from the iothread, I use the trick of using a bottom half to get that working correctly. but this _implementation_ is ugly as hell. Is there an easy way of doing it? - Do I really have to export last_ram_offset(), there is no other way of knowing the ammount of RAM? Known issues: - for some reason, when it has to start a 2nd round of bitmap handling, it decides to dirty all pages. Haven't found still why this happens. If you can test it, and said me where it breaks, it would also help. Work is based on Umesh thread work, and work that Paolo Bonzini had work on top of that. All the mirgation thread was done from scratch becase I was unable to debug why it was failing, but it "owes" a lot to the previous design. Thanks in advance, Juan. The following changes since commit a21143486b9c6d7a50b7b62877c02b3c686943cb: Merge remote-tracking branch 'stefanha/net' into staging (2012-07-23 13:15:34 -0500) are available in the git repository at: http://repo.or.cz/r/qemu/quintela.git migration-thread-v1 for you to fetch changes up to 27e539b03ba97bc37e107755bcb44511ec4c8100: buffered_file: unfold buffered_append in buffered_put_buffer (2012-07-24 16:46:13 +0200) Juan Quintela (23): buffered_file: g_realloc() can't fail savevm: Factorize ram globals reset in its own function ram: introduce migration_bitmap_set_dirty() ram: Introduce migration_bitmap_test_and_reset_dirty() ram: Export last_ram_offset() ram: introduce migration_bitmap_sync() Separate migration bitmap buffered_file: rename opaque to migration_state buffered_file: opaque is MigrationState buffered_file: unfold migrate_fd_put_buffer buffered_file: unfold migrate_fd_put_ready buffered_file: unfold migrate_fd_put_buffer buffered_file: unfold migrate_fd_put_buffer buffered_file: We can access directly to bandwidth_limit buffered_file: Move from using a timer to use a thread migration: make qemu_fopen_ops_buffered() return void migration: stop all cpus correctly migration: make writes blocking migration: remove unfreeze logic migration: take finer locking buffered_file: Unfold the trick to restart generating migration data buffered_file: don't flush on put buffer buffered_file: unfold buffered_append in buffered_put_buffer Paolo Bonzini (2): split MRU ram list BufferedFile: append, then flush Umesh Deshpande (2): add a version number to ram_list protect the ramlist with a separate mutex arch_init.c | 108 +++++++++++++++++++++++++------- buffered_file.c | 179 +++++++++++++++++------------------------------------- buffered_file.h | 12 +--- cpu-all.h | 17 +++++- exec-obsolete.h | 10 --- exec.c | 45 +++++++++++--- migration-exec.c | 2 - migration-fd.c | 6 -- migration-tcp.c | 2 +- migration-unix.c | 2 - migration.c | 111 ++++++++++++++------------------- migration.h | 6 ++ qemu-file.h | 5 -- savevm.c | 5 -- 14 files changed, 249 insertions(+), 261 deletions(-)