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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
