[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h h
From: |
n schembr |
Subject: |
Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...) |
Date: |
Fri, 27 Jul 2007 15:59:15 -0700 (PDT) |
----- Original Message ----
From: Paul Brook <address@hidden>
To: address@hidden
Cc: n schembr <address@hidden>
Sent: Friday, July 27, 2007 1:38:19 PM
Subject: Re: QEMU Automated Testing (was [Qemu-devel] qemu Makefile.target vl.h
hw/acpi.c hw/adlib.c ...)
> >As Qemu cannot use multicore CPUs (partially due to missing thread
> >safety), yet, you won't benefit from this unless you want to run
> >multiple instances of Qemu in parallel.
>
> how close is thread safey?
In a useful form: a fair way off.
It's relatively simple to hack something together than runs. Making it work
correctly and go fast is much harder though. My current prototype (running on
2 cores) runs about a quarter the speed of normal qemu, and dies shortly
after booting because the guest atomic synchronisation primitives don't work
right.
Either way, for a tinderbox or automated testing yo *do* have lots of
different tests you can run in parallel, so it doesn't matter that each qemu
instance only uses one core. We're only talking about small SMP here - maybe
16 cores, but not thousands.
Paul
-------------------------------------------------------------
Is the the issue I had with qemu moving from cpu to cpu? taskset -c 1 qemu or
notsc
http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00652.html
http://qemu-forum.ipi.fi/viewtopic.php?t=3714&highlight=taskset
What about preforking the processes one per virtual cpu?