qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] tests/migration: Allow longer timeouts


From: Thomas Huth
Subject: Re: [PATCH] tests/migration: Allow longer timeouts
Date: Tue, 13 Oct 2020 08:06:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 12/10/2020 15.13, Thomas Huth wrote:
> On 08/10/2020 18.03, Dr. David Alan Gilbert (git) wrote:
>> From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>>
>> In travis, with gcov and gprof we're seeing timeouts; hopefully fix
>> this by increasing the test timeouts a bit, but for xbzrle ensure it
>> really does get a couple of cycles through to test the cache.
>>
>> I think the problem in travis is we have about 2 host CPU threads,
>> in the test we have at least 3:
>>    a) The vCPU thread (100% flat out)
>>    b) The source migration thread
>>    c) The destination migration thread
>>
>> if (b) & (c) are slow for any reason - gcov+gperf or a slow host -
>> then they're sharing one host CPU thread so limit the migration
>> bandwidth.
>>
>> Tested on my laptop with:
>>    taskset -c 0,1 ./tests/qtest/migration-test -p /x86_64/migration
>>
>> Reported-by: Alex Bennée <alex.bennee@linaro.org>
>> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>> ---
>>  tests/qtest/migration-test.c | 21 +++++++++++----------
>>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> This seems to fix the gcov/gprof test indeed:
> 
>  https://travis-ci.com/github/huth/qemu/jobs/398270396
> 
> Thus:
> 
> Tested-by: Thomas Huth <thuth@redhat.com>
> 
> I'm also queuing this to my qtest-next branch (in case you don't plan a
> migration pull request within the next days):
> 
>  https://gitlab.com/huth/qemu/-/commits/qtest-next/

FYI, this patch fails to build on non-Linux systems:

https://cirrus-ci.com/task/5951706225704960?command=main#L6076

The #define needs to be moved out of the #if defined(__linux__) block. I can
fixup the patch here locally, but if you want to include it in your next
migration pull request instead, you should do that, too.

 Cheers,
  Thomas




reply via email to

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