From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH 5/5] Separate migration thread Date: Tue, 30 Aug 2011 09:31:50 -0300 Message-ID: <20110830123149.GB19450@amt.cnet> References: <893c5f1f472e252d9ae43a8348e0e0ef882936ce.1314466743.git.udeshpan@redhat.com> <20110829184949.GA4924@amt.cnet> <4E5CA3CB.5070707@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Umesh Deshpande , Anthony Liguori , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43145 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751273Ab1H3McO (ORCPT ); Tue, 30 Aug 2011 08:32:14 -0400 Content-Disposition: inline In-Reply-To: <4E5CA3CB.5070707@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Aug 30, 2011 at 10:48:11AM +0200, Paolo Bonzini wrote: > 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). Fair enough, its indeed generic except misuse of ram lock. > >>+ 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... Sounds good. > >+ 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyNUD-0001W8-Ut for qemu-devel@nongnu.org; Tue, 30 Aug 2011 08:32:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QyNUC-000358-NG for qemu-devel@nongnu.org; Tue, 30 Aug 2011 08:32:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QyNUC-000354-9g for qemu-devel@nongnu.org; Tue, 30 Aug 2011 08:32:12 -0400 Date: Tue, 30 Aug 2011 09:31:50 -0300 From: Marcelo Tosatti Message-ID: <20110830123149.GB19450@amt.cnet> References: <893c5f1f472e252d9ae43a8348e0e0ef882936ce.1314466743.git.udeshpan@redhat.com> <20110829184949.GA4924@amt.cnet> <4E5CA3CB.5070707@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5CA3CB.5070707@redhat.com> Subject: Re: [Qemu-devel] [PATCH 5/5] Separate migration thread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , Umesh Deshpande , qemu-devel@nongnu.org, kvm@vger.kernel.org On Tue, Aug 30, 2011 at 10:48:11AM +0200, Paolo Bonzini wrote: > 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). Fair enough, its indeed generic except misuse of ram lock. > >>+ 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... Sounds good. > >+ 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