[Top][All Lists]
[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