From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXSRz-0007KW-Ng for qemu-devel@nongnu.org; Mon, 16 Mar 2015 06:40:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXSRs-0007WG-KY for qemu-devel@nongnu.org; Mon, 16 Mar 2015 06:40:47 -0400 Received: from mail.ispras.ru ([83.149.199.45]:51277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXSRs-0007Vd-14 for qemu-devel@nongnu.org; Mon, 16 Mar 2015 06:40:40 -0400 From: "Pavel Dovgaluk" References: <20150227130939.11912.50660.stgit@PASHA-ISP> <20150227131131.11912.52470.stgit@PASHA-ISP> <550317FA.6090301@redhat.com> In-Reply-To: <550317FA.6090301@redhat.com> Date: Mon, 16 Mar 2015 13:40:36 +0300 Message-ID: <000d01d05fd5$a4240080$ec6c0180$@Dovgaluk@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: ru Subject: Re: [Qemu-devel] [RFC PATCH v10 18/24] replay: replay aio requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Paolo Bonzini' , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, alex.bennee@linaro.org, mark.burton@greensocs.com, real@ispras.ru, batuzovk@ispras.ru, maria.klimushenkova@ispras.ru, afaerber@suse.de, fred.konrad@greensocs.com > From: Paolo Bonzini [mailto:pbonzini@redhat.com] > On 27/02/2015 14:11, Pavel Dovgalyuk wrote: > > This patch adds identifier to aio requests. ID is used for creating bottom > > halves and identifying them while replaying. > > The patch also introduces several functions that make possible replaying > > of the aio requests. > > Out of curiosity, why did you use this approach instead of using a > RR-specific block device backend (as you did for network, I think)? The > backend could just store the data that is read in the RR file (or in a > separate file that can be easily mmap-ed), and use a timer to trigger it > at the right QEMU_CLOCK_VIRTUAL tick. > > I'm sure you considered something like this. Did you still get > non-determinism? We considered this approach. But it requires too much data to be written. E.g. when loading an OS guest VM reads gigabytes of data. Writing all this data to file incurs significant slowdown. Pavel Dovgalyuk