qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] make check speed


From: Thomas Huth
Subject: Re: [Qemu-devel] make check speed
Date: Wed, 23 Aug 2017 10:35:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

On 23.08.2017 10:01, Paolo Bonzini wrote:
> On 23/08/2017 09:49, Thomas Huth wrote:
>> While we're at it: I'd like to have a "make check-fast", too. Sometimes
>> the normal "make check" is already too slow, e.g. while developing new
>> patches, I sometimes just want to do a very quick sanity test to see
>> whether I broke some basic things or not, and only do the "make check"
>> before I submit my patches.
>> So we would get three stages:
>>
>> - make check-fast => For very, very quick sanity tests only
>>
>> - make check => E.g. has to be run before submitting patches
>>
>> - make check-harder => might run a very long time, so best suited for
>>                        nightly regression tests etc.?
>>
>> Does that sound reasonable? And the crucial question: Who is going to
>> implement the basic framework for this?
> 
> There's already make check-unit or make check-qtest-x86_64 depending on
> what you're working on.

True. And I just learned that you can also already set the SPEED
variable to either "quick" or "slow" and that we're already using
g_test_quick() and g_test_slow() in a couple of places to check this. So
the framework for running quick vs. thorough tests is already there ...
we just might want to add this to some more tests, I guess...

Question for the maintainers and the test automation folks: Is anybody
already running "make check SPEED=slow" or is this just rather an
unheard-of way of running the tests?

> If you have a many-core machine, of course, there's no simpler solution
> than throwing more CPUs at it. :)

Is it safe nowadays to run "make check -j4" for example? Last time I
tried (maybe 1 or 2 years ago), there were still issues since some tests
were using hard-coded temporary file names, so the parallel tests were
disturbing each other, for example...

 Thomas



reply via email to

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