qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: request : qemu-smp as target


From: Mark Williamson
Subject: Re: [Qemu-devel] Re: request : qemu-smp as target
Date: Wed, 18 May 2005 12:29:38 +0100
User-agent: KMail/1.8

> But how often will the virtual CPUs need the same page and is there any
> other shared resource other than memory?  I don't know how independent
> each CPU is.  Though in side discussions, everyone agrees with you, I
> haven't seen numbers to convince my gut.  If page only needs to be
> faulted back and forth every couple million cycles, then it might work.

In the applications, probably very independent.  In the kernel, highly 
dependent: different CPUs may access shared data structures *and* protect 
them with spinlocks.  As Paul said in a separate mail, spinlocks are going to 
be way more expensive in this sort of distributed environment.

All that being said, a company called "Virtual Iron" has got a 
fully-virtualising solution that presents an SMP to the guest OS but actually 
distributes computation across a cluster.  I have yet to see the product 
itself - no idea when it'll be released.  It also sounds *really* difficult 
to make go fast but at least suggests this sort of thing can perform 
reasonably for some workloads.

Cheers,
Mark

> > The only solution I can imagine being even vaguely worthwhile is a
> > running user-mode qemu on top of a native openmozix system.
>
> OpenMosix is very interesting, but is a pain to setup.  How about this:
>
>   ssh -f host1 qemu -cpu-server $KEY
>   ssh -f host2 qemu -cpu-server $KEY
>   qemu -cpu-client host1:$KEY \
>        -cpu-client host2:$KEY \
>        -hda server.image
>
> > > I have ignorantly implemented an SH2 emulator,
> >
> > Cool. Any chance you're going to make these changes publicly available?
>
> It was a Java implementation for a customer.  Not my property and not
> integrated with any free software.
>
> > Paul




reply via email to

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