qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/6] Migration pull


From: Thomas Huth
Subject: Re: [Qemu-devel] [Qemu-ppc] [PULL 0/6] Migration pull
Date: Thu, 9 Feb 2017 14:06:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 09.02.2017 11:43, Peter Maydell wrote:
> On 8 February 2017 at 08:47, Thomas Huth <address@hidden> wrote:
>> How fast is that aarch64 machine?
> 
> It's a juno board, so it's not very fast, but I wouldn't
> have expected it to hit a 100 second timeout assuming
> the test isn't trying to do a ludicrous amount of work.
> 
>> The timeout of the prom-env test is
>> already 100 seconds, so that seems to be plenty to me (the test normally
>> finishes here on my laptop within 15 seconds).
>> OTOH, if it helps with the aarch64 machine, I'm also fine if we increase
>> the timeout further - but what value would be appropriate then? Could you
>> please run the following on that slow machine:
>>
>>  time QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 tests/prom-env-test
[....]
> <qemu-system-ppc64 tests/prom-env-test -v -p /ppc64/prom-env/pseries
> /ppc64/prom-env/pseries: OK
> 
> real    1m24.362s
> user    1m23.572s
> sys     0m1.144s
> 
> pseries is much slower than the other two and at 85 seconds is
> not all that much below the 100s. Something's odd here.

SLOF (the firmware of the pseries machine) is known to perform quite bad
when running under TCG ... maybe it is even worse with the ARM version
of TCG? Or did you by any chance accidentially compile that version of
QEMU with "--enable-debug"?

Anyway, I've got some ideas how to speed up the test... and to be sure,
I'll also increase the timeout to 120 seconds instead. I'll send a patch
when it is ready...

 Thomas




reply via email to

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