qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] accel: allows to select the "best" accelera


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 1/2] accel: allows to select the "best" accelerator
Date: Wed, 5 Oct 2016 09:48:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0


On 05/10/2016 09:00, Thomas Huth wrote:
> On 04.10.2016 19:16, Paolo Bonzini wrote:
>>
>>
>> On 04/10/2016 16:18, Thomas Huth wrote:
>>>>>>> Using only tcg has also some disadvantages: For some tests, it's
>>>>>>> interesting to know whether they also work properly with KVM (e.g.
>>>>>>> migration tests), and only using tcg by default slows down the "make
>>>>>>> check" quite a bit - which might become an issue now that we're adding
>>>>>>> more and more tests.
>>>>>
>>>>> Which tests are you seeing a slow-down for ?
>>> Well, everything that is using accel=tcg in tests/ could be accelerated.
>>> For example, the new ipv6/ppc64 unit test is quite slow with TCG:
>>>
>>> sudo QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 time tests/pxe-test
>>>
>>>  48.46user 0.07system 0:48.48elapsed
>>
>> Could that point to a firmware bug?  10 network-bound seconds for a boot
>> makes some sense, but 10 CPU-bound seconds don't...
> 
> SLOF is incredibly slow with TCG - most parts are written in Forth that
> gets interpreted during runtime, and that seems to perform quite badly
> with TCG for some reasons. We're in progress of speeding up the boot
> process of SLOF a little bit (see
> https://github.com/aik/SLOF/commit/b3fde41bc75269df2 for example), but
> it will likely always be slower than a firmware that has been written in
> C only.

For what it's worth, just adding "-nodefaults -serial mon:stdio -net
nic,model=virtio -net user" saves 7 seconds (30%) on the time needed to
reach the OpenFirmware prompt.  SCSI seems to be the slowest device to scan.

Paolo




reply via email to

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