[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] QEMU redesigned for MPI (Message Passing Interface)

From: Jamie Lokier
Subject: Re: [Qemu-devel] QEMU redesigned for MPI (Message Passing Interface)
Date: Mon, 16 Nov 2009 22:57:22 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

Mulyadi Santosa wrote:
> Hi Victor...
> On 11/13/09, Victor Vasilchenko <address@hidden> wrote:
> > The only BIG question - what virtualization software can support MPI to
> > effectively work on cluster ?
> >
> > I am asking this question to QEMU team cause I believe QEMU can be the one.
> > If you have any ideas or experiments or information - please share with me.
> >
> > Kind Regards,
> > Victor.
> >
> If you check through Qemu list archieve, you shall see that there were
> more or less similar question: parallelization of Qemu.

> Most of the answers are: it can be hardly done. AFAIK, this is due
> to how dynamic translation is done... you need (most of the part I
> guess) almost 100% serialization.

I completely disagree.

Dynamic translation doesn't need 100% serialisation, but to relax that
it does require atomic ops and memory barriers (including implied
ones) in the guest to be translated to equivalents in the host.
Unfortunately x86 instructions imply a lot of barriers
(program-ordered writes), which is great for programming x86 but not
great when translating to non-x86 host code.

Right now, though, qemu's translator does not do that, even for
x86->x86, so it has to be serialised when running multi-CPU guest code.

KVM, on the other hand, does not do dynamic translation and can run
multiple threads in parallel because the atomic/barrier semantics are
preserved exactly.  KVM would be a fine candidate for running multiple
threads on different host machines.

You'd need to serialise memory using page faults, but such techniques
are already implemented with cluster filesystems and writable-mmap'd
files, so it might be possible to use KVM over that.

-- Jamie

reply via email to

[Prev in Thread] Current Thread [Next in Thread]