From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v5 4/5] Inter-VM shared memory PCI device Date: Tue, 11 May 2010 10:59:41 +0300 Message-ID: <4BE90E6D.7070007@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cam Macdonell , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11356 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751225Ab0EKH7p (ORCPT ); Tue, 11 May 2010 03:59:45 -0400 In-Reply-To: <4BE847CB.7050503@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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