[Qemu-devel] Re: [PATCH v5 4/5] Inter-VM shared memory PCI device

[Avi Kivity <avi@redhat.com>]

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