From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35188 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBkYD-0002RZ-NQ for qemu-devel@nongnu.org; Tue, 11 May 2010 04:10:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBkNV-0000hv-Sm for qemu-devel@nongnu.org; Tue, 11 May 2010 03:59:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2570) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OBkNV-0000hf-L8 for qemu-devel@nongnu.org; Tue, 11 May 2010 03:59:45 -0400 Message-ID: <4BE90E6D.7070007@redhat.com> Date: Tue, 11 May 2010 10:59:41 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1271872408-22842-1-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-3-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-4-git-send-email-cam@cs.ualberta.ca> <1271872408-22842-5-git-send-email-cam@cs.ualberta.ca> <4BE7F517.5010707@redhat.com> <4BE82623.4000905@redhat.com> <4BE82877.1040408@codemonkey.ws> <4BE83B69.4040904@redhat.com> <4BE84172.9080305@codemonkey.ws> <4BE847CB.7050503@codemonkey.ws> In-Reply-To: <4BE847CB.7050503@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Cam Macdonell , qemu-devel@nongnu.org, kvm@vger.kernel.org On 05/10/2010 08:52 PM, Anthony Liguori wrote: >>> Why try to attempt to support multi-master shared memory? What's the >>> use-case? >> I don't see it as multi-master, but that the latest guest to join >> shouldn't have their contents take precedence. In developing this >> patch, my motivation has been to let the guests decide. If the memcpy >> is always done, even when no data is written, a guest cannot join >> without overwriting everything. >> >> One use case we're looking at is having VMs using a map reduce >> framework like Hadoop or Phoenix running in VMs. However, if a >> workqueue is stored or data transfer passes through shared memory, a >> system can't scale up the number of workers because each new guest >> will erase the shared memory (and the workqueue or in progress data >> transfer). > > (Replying again to list) > > What data structure would you use? For a lockless ring queue, you can > only support a single producer and consumer. To achieve bidirectional > communication in virtio, we always use two queues. You don't have to use a lockless ring queue. You can use locks (spinlocks without interrupt support, full mutexes with interrupts) and any data structure you like. Say a hash table + LRU for a shared cache. > > If you're adding additional queues to support other levels of > communication, you can always use different areas of shared memory. You'll need O(n^2) shared memory areas (n=peer count), and it is a lot less flexible that real shared memory. Consider using threading where the only communication among threads is a pipe (erlang?) -- error compiling committee.c: too many arguments to function