From: "Alex Bennée" <alex.bennee@linaro.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-trivial@nongnu.org,
qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-trivial] [PATCH v3 2/3] .travis.yml: run make check for all matrix targets
Date: Sun, 31 Jan 2016 08:37:49 +0000 [thread overview]
Message-ID: <878u36ywiq.fsf@linaro.org> (raw)
In-Reply-To: <20160130123502.GQ23043@voom.redhat.com>
David Gibson <david@gibson.dropbear.id.au> writes:
> On Thu, Jan 28, 2016 at 02:23:28PM +0000, Alex Bennée wrote:
>> We only ran make check once before it used to be an unreliable target.
>> It was only a stop gap measure and we should be able to revert it now.
>> This also stops us needing a large all-MMU build.
>>
>> We disable "make check" for a couple of the extra config targets which
>> are currently broken.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
> So, in general I like the idea of running make check more widely.
>
> However.. I was wondering - what's the rationale for having separate
> matrix builds for each target (or small group) rather than just doing
> one build with all the targets?
Each individual part of the matrix can be run in parallel with the
others so it makes sense to keep the build component small (as each
softmmu target rebuilds a significant chunk of the build).
Having said that there is a fair amount of repetition as we are
repeating all the generic qtests each time just so we can run the extra
${TARGET}-qtest binaries.
Travis does has an option for using ccache so it might be worth
experimenting with that to see if things are improved.
> I can't see any obvious benefit to splitting the build that way, but
> it does increase the total build time significantly - and will do so
> rather more so with make check added.
Elapsed and total are the ones to look at:
https://travis-ci.org/stsquad/qemu/builds/105401126
vs
https://travis-ci.org/qemu/qemu/builds/105711606
However it looks like Travis are having scaling growing pains because
there "old style" VM approach is running a lot faster than it used to.
>
>> ---
>> .travis.yml | 15 ++++++++-------
>> 1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 4a0c23a..16be23f 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -40,7 +40,7 @@ notifications:
>> on_failure: always
>> env:
>> global:
>> - - TEST_CMD=""
>> + - TEST_CMD="make check"
>> - EXTRA_CONFIG=""
>> matrix:
>> # Group major targets together with their linux-user counterparts
>> @@ -73,17 +73,14 @@ script:
>> matrix:
>> # We manually include a number of additional build for non-standard bits
>> include:
>> - # Make check target (we only do this once)
>> - - env:
>> - - TARGETS=alpha-softmmu,arm-softmmu,aarch64-softmmu,cris-softmmu,i386-softmmu,x86_64-softmmu,m68k-softmmu,microblaze-softmmu,microblazeel-softmmu,mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu,or32-softmmu,ppc-softmmu,ppc64-softmmu,ppcemb-softmmu,s390x-softmmu,sh4-softmmu,sh4eb-softmmu,sparc-softmmu,sparc64-softmmu,unicore32-softmmu,lm32-softmmu,moxie-softmmu,tricore-softmmu,xtensa-softmmu,xtensaeb-softmmu
>> - TEST_CMD="make check"
>> - compiler: gcc
>> # Debug related options
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-debug"
>> compiler: gcc
>> + # We currently disable "make check"
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-debug --enable-tcg-interpreter"
>> + TEST_CMD=""
>> compiler: gcc
>> # Disable a few of the optional features
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> @@ -104,11 +101,15 @@ matrix:
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-trace-backends=simple"
>> compiler: gcc
>> + # We currently disable "make check"
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-trace-backends=ftrace"
>> + TEST_CMD=""
>> compiler: gcc
>> + # We currently disable "make check"
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> - EXTRA_CONFIG="--enable-trace-backends=ust"
>> + EXTRA_CONFIG="--enable-trace-backends=ust"
>> + TEST_CMD=""
>> compiler: gcc
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-modules"
--
Alex Bennée
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-trivial@nongnu.org,
qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 2/3] .travis.yml: run make check for all matrix targets
Date: Sun, 31 Jan 2016 08:37:49 +0000 [thread overview]
Message-ID: <878u36ywiq.fsf@linaro.org> (raw)
In-Reply-To: <20160130123502.GQ23043@voom.redhat.com>
David Gibson <david@gibson.dropbear.id.au> writes:
> On Thu, Jan 28, 2016 at 02:23:28PM +0000, Alex Bennée wrote:
>> We only ran make check once before it used to be an unreliable target.
>> It was only a stop gap measure and we should be able to revert it now.
>> This also stops us needing a large all-MMU build.
>>
>> We disable "make check" for a couple of the extra config targets which
>> are currently broken.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
> So, in general I like the idea of running make check more widely.
>
> However.. I was wondering - what's the rationale for having separate
> matrix builds for each target (or small group) rather than just doing
> one build with all the targets?
Each individual part of the matrix can be run in parallel with the
others so it makes sense to keep the build component small (as each
softmmu target rebuilds a significant chunk of the build).
Having said that there is a fair amount of repetition as we are
repeating all the generic qtests each time just so we can run the extra
${TARGET}-qtest binaries.
Travis does has an option for using ccache so it might be worth
experimenting with that to see if things are improved.
> I can't see any obvious benefit to splitting the build that way, but
> it does increase the total build time significantly - and will do so
> rather more so with make check added.
Elapsed and total are the ones to look at:
https://travis-ci.org/stsquad/qemu/builds/105401126
vs
https://travis-ci.org/qemu/qemu/builds/105711606
However it looks like Travis are having scaling growing pains because
there "old style" VM approach is running a lot faster than it used to.
>
>> ---
>> .travis.yml | 15 ++++++++-------
>> 1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 4a0c23a..16be23f 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -40,7 +40,7 @@ notifications:
>> on_failure: always
>> env:
>> global:
>> - - TEST_CMD=""
>> + - TEST_CMD="make check"
>> - EXTRA_CONFIG=""
>> matrix:
>> # Group major targets together with their linux-user counterparts
>> @@ -73,17 +73,14 @@ script:
>> matrix:
>> # We manually include a number of additional build for non-standard bits
>> include:
>> - # Make check target (we only do this once)
>> - - env:
>> - - TARGETS=alpha-softmmu,arm-softmmu,aarch64-softmmu,cris-softmmu,i386-softmmu,x86_64-softmmu,m68k-softmmu,microblaze-softmmu,microblazeel-softmmu,mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu,or32-softmmu,ppc-softmmu,ppc64-softmmu,ppcemb-softmmu,s390x-softmmu,sh4-softmmu,sh4eb-softmmu,sparc-softmmu,sparc64-softmmu,unicore32-softmmu,lm32-softmmu,moxie-softmmu,tricore-softmmu,xtensa-softmmu,xtensaeb-softmmu
>> - TEST_CMD="make check"
>> - compiler: gcc
>> # Debug related options
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-debug"
>> compiler: gcc
>> + # We currently disable "make check"
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-debug --enable-tcg-interpreter"
>> + TEST_CMD=""
>> compiler: gcc
>> # Disable a few of the optional features
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> @@ -104,11 +101,15 @@ matrix:
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-trace-backends=simple"
>> compiler: gcc
>> + # We currently disable "make check"
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-trace-backends=ftrace"
>> + TEST_CMD=""
>> compiler: gcc
>> + # We currently disable "make check"
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> - EXTRA_CONFIG="--enable-trace-backends=ust"
>> + EXTRA_CONFIG="--enable-trace-backends=ust"
>> + TEST_CMD=""
>> compiler: gcc
>> - env: TARGETS=i386-softmmu,x86_64-softmmu
>> EXTRA_CONFIG="--enable-modules"
--
Alex Bennée
next prev parent reply other threads:[~2016-01-31 8:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 14:23 [Qemu-trivial] [PATCH v3 0/3] Travis updates Alex Bennée
2016-01-28 14:23 ` [Qemu-devel] " Alex Bennée
2016-01-28 14:23 ` [Qemu-trivial] [PATCH v3 1/3] .travis.yml: migrate to container builds Alex Bennée
2016-01-28 14:23 ` [Qemu-devel] " Alex Bennée
2016-01-28 14:23 ` [Qemu-trivial] [PATCH v3 2/3] .travis.yml: run make check for all matrix targets Alex Bennée
2016-01-28 14:23 ` [Qemu-devel] " Alex Bennée
2016-01-30 12:35 ` [Qemu-trivial] " David Gibson
2016-01-30 12:35 ` [Qemu-devel] " David Gibson
2016-01-31 8:37 ` Alex Bennée [this message]
2016-01-31 8:37 ` Alex Bennée
2016-01-31 10:27 ` [Qemu-trivial] " David Gibson
2016-01-31 10:27 ` [Qemu-devel] " David Gibson
2016-01-28 14:23 ` [Qemu-trivial] [PATCH v3 3/3] .travis.yml: enable each of the co-routine backends Alex Bennée
2016-01-28 14:23 ` [Qemu-devel] " Alex Bennée
2016-01-30 9:48 ` [Qemu-trivial] [PATCH v3 0/3] Travis updates Michael Tokarev
2016-01-30 9:48 ` [Qemu-devel] " Michael Tokarev
2016-01-31 8:43 ` [Qemu-trivial] " Alex Bennée
2016-01-31 8:43 ` [Qemu-devel] " Alex Bennée
2016-01-31 12:05 ` [Qemu-trivial] " Peter Maydell
2016-01-31 12:05 ` [Qemu-devel] " Peter Maydell
2016-02-02 7:59 ` [Qemu-trivial] " Michael Tokarev
2016-02-02 7:59 ` [Qemu-devel] " Michael Tokarev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878u36ywiq.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=david@gibson.dropbear.id.au \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.