All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>,
	qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH 0/2] run_tests: support concurrent test execution
Date: Mon, 2 Jan 2017 21:25:56 +0100	[thread overview]
Message-ID: <20170102202555.GF2395@potion> (raw)
In-Reply-To: <38d74124-eb01-c381-8dd9-2a6334c71fa3@redhat.com>

2017-01-02 18:07+0100, Paolo Bonzini:
> On 01/01/2017 11:34, Peter Xu wrote:
>> run_tests.sh is getting slower. Maybe it's time to let it run faster.
>> An obvious issue is that, we were running the tests sequentially in
>> the past.
>> 
>> This series provides another new "-j" parameter. "-j 8" means we run
>> the tests on 8 task queues. That'll fasten the script a lot. A very
>> quick test of mine shows 3x speed boost with 8 task queues.
>> 
>> Most of the changes are in scripts/tash.bash of patch 2, which
>> implemented the main logic for task managements. Please see commit
>> message for more information.
>> 
>> I did a quick "make standalone" test to make sure this series won't
>> break it. However I am not sure whether it'll break other thing that I
>> don't know...
> 
> Would it work if run_tests.sh wrote a Makefile for all the tests (with
> phony targets only), and then simply ran "make -f Makefile.tmp -jN"?

We would need to change for_each_unittest to print the command line
instead of running it and add a executable wrapper for run() from
scripts/runtime.bash to have something to pass those arguments to.
After that, we could generate a Makefile.

I think we can do the queue with ~3 lines of bash and the Makefile would
complicate it more.

Btw. I just leaned that xargs provides a simpler, but sufficient,
queueing functionality, e.g.

  echo "echo a\0 (sleep 1; echo b)\0 echo c\0 sleep 1\0 echo d" |
    xargs -0 -L 1 -P 2 sh -c

WARNING: multiple messages have this Message-ID (diff)
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Xu <peterx@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Andrew Jones <drjones@redhat.com>
Subject: Re: [Qemu-devel] [kvm-unit-tests PATCH 0/2] run_tests: support concurrent test execution
Date: Mon, 2 Jan 2017 21:25:56 +0100	[thread overview]
Message-ID: <20170102202555.GF2395@potion> (raw)
In-Reply-To: <38d74124-eb01-c381-8dd9-2a6334c71fa3@redhat.com>

2017-01-02 18:07+0100, Paolo Bonzini:
> On 01/01/2017 11:34, Peter Xu wrote:
>> run_tests.sh is getting slower. Maybe it's time to let it run faster.
>> An obvious issue is that, we were running the tests sequentially in
>> the past.
>> 
>> This series provides another new "-j" parameter. "-j 8" means we run
>> the tests on 8 task queues. That'll fasten the script a lot. A very
>> quick test of mine shows 3x speed boost with 8 task queues.
>> 
>> Most of the changes are in scripts/tash.bash of patch 2, which
>> implemented the main logic for task managements. Please see commit
>> message for more information.
>> 
>> I did a quick "make standalone" test to make sure this series won't
>> break it. However I am not sure whether it'll break other thing that I
>> don't know...
> 
> Would it work if run_tests.sh wrote a Makefile for all the tests (with
> phony targets only), and then simply ran "make -f Makefile.tmp -jN"?

We would need to change for_each_unittest to print the command line
instead of running it and add a executable wrapper for run() from
scripts/runtime.bash to have something to pass those arguments to.
After that, we could generate a Makefile.

I think we can do the queue with ~3 lines of bash and the Makefile would
complicate it more.

Btw. I just leaned that xargs provides a simpler, but sufficient,
queueing functionality, e.g.

  echo "echo a\0 (sleep 1; echo b)\0 echo c\0 sleep 1\0 echo d" |
    xargs -0 -L 1 -P 2 sh -c

  reply	other threads:[~2017-01-02 20:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-01 10:34 [kvm-unit-tests PATCH 0/2] run_tests: support concurrent test execution Peter Xu
2017-01-01 10:34 ` [Qemu-devel] " Peter Xu
2017-01-01 10:34 ` [kvm-unit-tests PATCH 1/2] run_tests: provide RUNTIME_log_file Peter Xu
2017-01-01 10:34   ` [Qemu-devel] " Peter Xu
2017-01-01 10:34 ` [kvm-unit-tests PATCH 2/2] run_tests: allow run tests in parallel Peter Xu
2017-01-01 10:34   ` [Qemu-devel] " Peter Xu
2017-01-02 20:18   ` Radim Krčmář
2017-01-02 20:18     ` [Qemu-devel] " Radim Krčmář
2017-01-03  2:45     ` Peter Xu
2017-01-03  2:45       ` [Qemu-devel] " Peter Xu
2017-01-04 14:55       ` Radim Krčmář
2017-01-04 14:55         ` [Qemu-devel] " Radim Krčmář
2017-01-05  2:35         ` Peter Xu
2017-01-05  2:35           ` [Qemu-devel] " Peter Xu
2017-01-05 20:31           ` Radim Krčmář
2017-01-05 20:31             ` [Qemu-devel] " Radim Krčmář
2017-01-02 17:07 ` [kvm-unit-tests PATCH 0/2] run_tests: support concurrent test execution Paolo Bonzini
2017-01-02 17:07   ` [Qemu-devel] " Paolo Bonzini
2017-01-02 20:25   ` Radim Krčmář [this message]
2017-01-02 20:25     ` Radim Krčmář
2017-01-03  2:50     ` Peter Xu
2017-01-03  2:50       ` [Qemu-devel] " Peter Xu
2017-01-03  3:03   ` Peter Xu
2017-01-03  3:03     ` [Qemu-devel] " Peter Xu
2017-01-03  9:31     ` Paolo Bonzini
2017-01-03  9:31       ` [Qemu-devel] " Paolo Bonzini

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=20170102202555.GF2395@potion \
    --to=rkrcmar@redhat.com \
    --cc=drjones@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.