From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yoshiaki Tamura Subject: Re: [RFC PATCH 04/20] Make QEMUFile buf expandable, and introduce qemu_realloc_buffer() and qemu_clear_buffer(). Date: Mon, 26 Apr 2010 19:43:25 +0900 Message-ID: <4BD56E4D.3050309@lab.ntt.co.jp> References: <1271829445-5328-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <1271829445-5328-5-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <4BD16E30.5080502@redhat.com> <4BD16F8C.5010007@lab.ntt.co.jp> <4BD19D42.4060009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, aliguori@us.ibm.com, mtosatti@redhat.com, ohmura.kei@lab.ntt.co.jp, yoshikawa.takuya@oss.ntt.co.jp To: Avi Kivity Return-path: Received: from tama500.ecl.ntt.co.jp ([129.60.39.148]:50375 "EHLO tama500.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751590Ab0DZKnu (ORCPT ); Mon, 26 Apr 2010 06:43:50 -0400 In-Reply-To: <4BD19D42.4060009@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > On 04/23/2010 12:59 PM, Yoshiaki Tamura wrote: >> Avi Kivity wrote: >>> On 04/21/2010 08:57 AM, Yoshiaki Tamura wrote: >>>> Currently buf size is fixed at 32KB. It would be useful if it could >>>> be flexible. >>>> >>> >>> Why is this needed? The real buffering is in the kernel anyways; this is >>> only used to reduce the number of write() syscalls. >> >> This was introduced to buffer the transfered guests image transaction >> ally on the receiver side. The sender doesn't use it. >> In case of intermediate state, we just discard this buffer. > > How large can it grow? It really depends on what workload is running on the guest, but it should be as large as the guest ram size in the worst case. > What's wrong with applying it (perhaps partially) to the guest state? > The next state transfer will overwrite it completely, no? AFAIK, the answer is no. qemu_loadvm_state() calls load handlers of each device emulator, and they will update its state directly, which means even if the transaction was not complete, it's impossible to recover the previous state if we don't make a buffer. I guess your concern is about consuming large size of ram, and I think having an option for writing the transaction to a temporal disk image should be effective.