From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyJzW-0002fe-VE for qemu-devel@nongnu.org; Tue, 30 Aug 2011 04:48:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QyJzV-00071i-QH for qemu-devel@nongnu.org; Tue, 30 Aug 2011 04:48:18 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:55882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyJzV-00071e-NT for qemu-devel@nongnu.org; Tue, 30 Aug 2011 04:48:17 -0400 Received: by yih10 with SMTP id 10so4746544yih.4 for ; Tue, 30 Aug 2011 01:48:17 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4E5CA3CB.5070707@redhat.com> Date: Tue, 30 Aug 2011 10:48:11 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <893c5f1f472e252d9ae43a8348e0e0ef882936ce.1314466743.git.udeshpan@redhat.com> <20110829184949.GA4924@amt.cnet> In-Reply-To: <20110829184949.GA4924@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/5] Separate migration thread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Anthony Liguori , Umesh Deshpande , qemu-devel@nongnu.org, kvm@vger.kernel.org On 08/29/2011 08:49 PM, Marcelo Tosatti wrote: >> > -static void buffered_rate_tick(void *opaque) >> > +static void *migrate_vm(void *opaque) >> > { > > buffered_file.c was generic code that has now become migration specific > (although migration was the only user). So it should either stop > pretending to be generic code, by rename to migration_thread.c along > with un-exporting interfaces, or it should remain generic and therefore > all migration specific knowledge moved somewhere else. Actually, the thread function is ill-named. buffered_file.c is still generic code (or if it is not, it's a bug), except it should be called threaded_file.c. Moving it to migration.c is also an option of course. I asked Umesh to keep the abstraction for now, because it helped pinpointing places where abstractions were leaking in (such as the qemu_mutex_unlock_migrate_ram call that you found). >> + int64_t current_time, expire_time = qemu_get_clock_ms(rt_clock) + 100; >> + struct timeval tv = { .tv_sec = 0, .tv_usec = 100000}; > > qemu_get_clock_ms should happen under iothread lock. For rt_clock it is safe. Should be documented, though. >> + qemu_mutex_lock_migrate_ram(); >> s = migrate_to_fms(current_migration); >> if (s && s->file) { >> qemu_file_set_rate_limit(s->file, max_throttle); >> } >> + qemu_mutex_unlock_migrate_ram(); > > This lock protects the RAMlist, and only the RAMlist, but here its > being used to protect migration thread data. As noted above, a new lock > should be introduced. Even better, freeing the buffered_file should be only done in the iothread (if this is not the case) so that the lock can be pushed down to buffered_set_rate_limit... > + qemu_mutex_lock_migrate_ram(); > if (qemu_fclose(s->file) != 0) { > ret = -1; > } > + qemu_mutex_unlock_migrate_ram(); ... and buffered_close (if a lock turns out to be needed at all). Paolo