Re: qemu on a recent -current, slow like a 486 !

On Mon, Sep 03, 2007 at 08:54:57PM -0300, Nenhum_de_Nos wrote:
> On 9/3/07, Bruce Cran <bruce_at_cran.org.uk> wrote:
> > Nenhum_de_Nos wrote:
> > > I have disabled all but one debug support:
> > >
> > > makeoptions     DEBUG=-g                # Build kernel with gdb(1) debug symbols
> > >
> > > no witness also
> > >
> > > thanks
> > >
> > > matheus
> > >
> > >
> >
> > Hi Matheus,
> >
> > If you haven't tried kqemu-kmod, I would highly recommend it - with the
> > caveat that, being a kernel module that hasn't been extensively tested,
> > it may crash your system.
> > It should speed up qemu to near-native speeds since it allows the code
> > to run natively instead of being interpreted one instruction at a time.
> >
> > Cheers,
> > Bruce Cran
> 
> hm, I'll try this today :)
> thanks, but now what I think will most kill performance is that even
> though I say -smp 2 and it has two cpus (my machine is in fact dual
> core), it has one and only one process for all qemu vm, and there fore
> uses just one core.
> 
> is it really supposed to behave this way ?

-smp is meant more for testing purposes than running stuff where
performance matters, qemu is still single-threaded and -smp doesn't work
with kqemu...  Oh and if you want to use kqemu don't forget to rebuild
qemu with kqemu support enabled to get the relevant bits compiled in
(do `make config' to get the OPTIONS menu back), that will also build
kqemu as a dependency so you don't need to build that seperately.

 Also there is -kernel-kqemu too, altho not all guests really work
with that.  (freebsd guests mostly work, I have seen guest kernels
complain about the clock going backwards tho.)

 HTH,
	Juergen