From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm Date: Tue, 25 May 2010 17:01:19 +0300 Message-ID: <4BFBD82F.3020404@redhat.com> References: <20100519192222.GD61706@ncolin.muc.de> <4BF5A9D2.5080609@codemonkey.ws> <4BF91937.2070801@redhat.com> <4BFBAE46.5050801@redhat.com> <4BFBB3C1.9020905@redhat.com> <4BFBCFAC.9070807@codemonkey.ws> <4BFBD13C.60605@redhat.com> <4BFBD20E.5060207@codemonkey.ws> <4BFBD2D5.2000201@redhat.com> <4BFBD6CD.3000503@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:42051 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755123Ab0EYOBc (ORCPT ); Tue, 25 May 2010 10:01:32 -0400 In-Reply-To: <4BFBD6CD.3000503@codemonkey.ws> Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Anthony Liguori Cc: Kevin Wolf , Blue Swirl , ceph-devel@vger.kernel.org, Christian Brunner , kvm@vger.kernel.org, qemu-devel@nongnu.org On 05/25/2010 04:55 PM, Anthony Liguori wrote: > On 05/25/2010 08:38 AM, Avi Kivity wrote: >> On 05/25/2010 04:35 PM, Anthony Liguori wrote: >>> On 05/25/2010 08:31 AM, Avi Kivity wrote: >>>>> A protocol based mechanism has the advantage of being more robust >>>>> in the face of poorly written block backends so if it's possible >>>>> to make it perform as well as a plugin, it's a preferable approach. >>>> >>>> May be hard due to difficulty of exposing guest memory. >>> >>> If someone did a series to add plugins, I would expect a very strong >>> argument as to why a shared memory mechanism was not possible or at >>> least plausible. >>> >>> I'm not sure I understand why shared memory is such a bad thing wrt >>> KVM. Can you elaborate? Is it simply a matter of fork()? >> >> fork() doesn't work in the with of memory hotplug. What else is there? >> > > Is it that fork() doesn't work or is it that fork() is very expensive? It doesn't work, fork() is done at block device creation time, which freezes the child memory map, while guest memory is allocated at hotplug time. fork() actually isn't very expensive since we use MADV_DONTFORK (probably fast enough for everything except realtime). It may be possible to do a processfd() which can be mmap()ed by another process to export anonymous memory using mmu notifiers, not sure how easy or mergeable that is. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37119 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGuhN-0001vP-5H for qemu-devel@nongnu.org; Tue, 25 May 2010 10:01:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGuhI-0006by-JQ for qemu-devel@nongnu.org; Tue, 25 May 2010 10:01:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62652) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGuhI-0006bZ-Bn for qemu-devel@nongnu.org; Tue, 25 May 2010 10:01:32 -0400 Message-ID: <4BFBD82F.3020404@redhat.com> Date: Tue, 25 May 2010 17:01:19 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm References: <20100519192222.GD61706@ncolin.muc.de> <4BF5A9D2.5080609@codemonkey.ws> <4BF91937.2070801@redhat.com> <4BFBAE46.5050801@redhat.com> <4BFBB3C1.9020905@redhat.com> <4BFBCFAC.9070807@codemonkey.ws> <4BFBD13C.60605@redhat.com> <4BFBD20E.5060207@codemonkey.ws> <4BFBD2D5.2000201@redhat.com> <4BFBD6CD.3000503@codemonkey.ws> In-Reply-To: <4BFBD6CD.3000503@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , kvm@vger.kernel.org, qemu-devel@nongnu.org, Blue Swirl , ceph-devel@vger.kernel.org, Christian Brunner On 05/25/2010 04:55 PM, Anthony Liguori wrote: > On 05/25/2010 08:38 AM, Avi Kivity wrote: >> On 05/25/2010 04:35 PM, Anthony Liguori wrote: >>> On 05/25/2010 08:31 AM, Avi Kivity wrote: >>>>> A protocol based mechanism has the advantage of being more robust >>>>> in the face of poorly written block backends so if it's possible >>>>> to make it perform as well as a plugin, it's a preferable approach. >>>> >>>> May be hard due to difficulty of exposing guest memory. >>> >>> If someone did a series to add plugins, I would expect a very strong >>> argument as to why a shared memory mechanism was not possible or at >>> least plausible. >>> >>> I'm not sure I understand why shared memory is such a bad thing wrt >>> KVM. Can you elaborate? Is it simply a matter of fork()? >> >> fork() doesn't work in the with of memory hotplug. What else is there? >> > > Is it that fork() doesn't work or is it that fork() is very expensive? It doesn't work, fork() is done at block device creation time, which freezes the child memory map, while guest memory is allocated at hotplug time. fork() actually isn't very expensive since we use MADV_DONTFORK (probably fast enough for everything except realtime). It may be possible to do a processfd() which can be mmap()ed by another process to export anonymous memory using mmu notifiers, not sure how easy or mergeable that is. -- error compiling committee.c: too many arguments to function