From mboxrd@z Thu Jan 1 00:00:00 1970 From: ya su Subject: Re: [PATCH 07/18] Introduce fault tolerant VM transaction QEMUFile and ft_mode. Date: Wed, 9 Mar 2011 16:01:49 +0800 Message-ID: References: <1298468927-19193-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <1298468927-19193-8-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <4D65D679.3010607@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: quintela@redhat.com, qemu-devel@nongnu.org, kvm-devel To: Yoshiaki Tamura Return-path: Received: from mail-yx0-f174.google.com ([209.85.213.174]:35149 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752478Ab1CIIBu convert rfc822-to-8bit (ORCPT ); Wed, 9 Mar 2011 03:01:50 -0500 Received: by yxs7 with SMTP id 7so126236yxs.19 for ; Wed, 09 Mar 2011 00:01:49 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Juan: It's especailly important for ft to be a standalone thread, as it may cause monitor to be blocked by network problems. what's your schedule, maybe I can help some. Yoshi: in the following code: + + s->file =3D qemu_fopen_ops(s, ft_trans_put_buffer, ft_trans_get_bu= ffer, + ft_trans_close, ft_trans_rate_limit, + ft_trans_set_rate_limit, NULL); + + return s->file; +} I think you should register ft_trans_get_rate_limit function, otherwise it will not transfer any block data at stage 2 in block_save_live function: if (stage =3D=3D 2) { /* control the rate of transfer */ while ((block_mig_state.submitted + block_mig_state.read_done) * BLOCK_SIZE < qemu_file_get_rate_limit(f)) { qemu_file_get_rate_limit will return 0, then it will not proceed to copy dirty block data. FYI. Green. 2011/2/24 Yoshiaki Tamura : > 2011/2/24 Juan Quintela : >> >> [ trimming cc to kvm & qemu lists] >> >> Yoshiaki Tamura wrote: >>> Juan Quintela wrote: >>>> Yoshiaki Tamura =A0wrote: >>>>> This code implements VM transaction protocol. =A0Like buffered_fi= le, it >>>>> sits between savevm and migration layer. =A0With this architectur= e, VM >>>>> transaction protocol is implemented mostly independent from other >>>>> existing code. >>>> >>>> Could you explain what is the difference with buffered_file.c? >>>> I am fixing problems on buffered_file, and having something that c= opies >>>> lot of code from there makes me nervous. >>> >>> The objective is different: >>> >>> buffered_file buffers data for transmission control. >>> ft_trans_file adds headers to the stream, and controls the transact= ion >>> between sender and receiver. >>> >>> Although ft_trans_file sometimes buffers date, but it's not the mai= n objective. >>> If you're fixing the problems on buffered_file, I'll keep eyes on t= hem. >>> >>>>> +typedef ssize_t (FtTransPutBufferFunc)(void *opaque, const void = *data, size_t size); >>>> >>>> Can we get some sharing here? >>>> typedef ssize_t (BufferedPutFunc)(void *opaque, const void *data, = size_t size); >>>> >>>> There are not so much types for a write function that the 1st elem= ent is >>>> one opaque :p >>> >>> You're right, but I want to keep ft_trans_file independent of >>> buffered_file at this point. =A0Once Kemari gets merged, I'm happy = to >>> work with you to fix the problems on buffered_file and ft_trans_fil= e, >>> and refactoring them. >> >> My goal is getting its own thread for migration on 0.15, that >> basically means that we can do rm buffered_file.c. =A0I guess that >> something similar could happen for kemari. > > That means both gets initiated by it's own thread, not like > current poll based. =A0I'm still skeptical whether Anthony agrees, > but I'll keep it in my mind. > >> But for now, this is just the start + handwaving, once I start doing= the >> work I will told you. > > Yes, please. > > Yoshi > >> >> Later, Juan. >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >