All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Argenziano <antonio.argenziano@intel.com>
To: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t v2 4/5] runner: New test runner
Date: Thu, 14 Jun 2018 13:14:52 -0700	[thread overview]
Message-ID: <c11c99ee-d5f9-46e4-9d63-a03c4d217a19@intel.com> (raw)
In-Reply-To: <20180614101828.ugtc6niy6gzhfwzw@platvala-desk.ger.corp.intel.com>



On 14/06/18 03:18, Petri Latvala wrote:
> On Wed, Jun 13, 2018 at 10:10:11AM -0700, Antonio Argenziano wrote:
>>
>>
>> On 13/06/18 03:07, Petri Latvala wrote:
>>> This is a new test runner to replace piglit. Piglit has been very
>>> useful as a test runner, but certain improvements have been very
>>> difficult if possible at all in a generic test running framework.
>>>
>>> Important improvements over piglit:
>>>
>>> - Faster to launch. Being able to make assumptions about what we're
>>>     executing makes it possible to save significant amounts of time. For
>>>     example, a testlist file's line "igt@somebinary@somesubtest" already
>>>     has all the information we need to construct the correct command
>>>     line to execute that particular subtest, instead of listing all
>>>     subtests of all test binaries and mapping them to command
>>>     lines. Same goes for the regexp filters command line flags -t and
>>>     -x; If we use -x somebinaryname, we don't need to list subtests from
>>>     somebinaryname, we already know none of them will get executed.
>>>
>>> - Logs of incomplete tests. Piglit collects test output to memory and
>>>     dumps them to a file when the test is complete. The new runner
>>>     writes all output to disk immediately.
>>>
>>> - Ability to execute multiple subtests in one binary execution. This
>>>     was possible with piglit, but its semantics made it very hard to
>>>     implement in practice. For example, having a testlist file not only
>>>     selected a subset of tests to run, but also mandated that they be
>>>     executed in the same order.
>>>
>>> - Flexible timeout support. Instead of mandating a time tests cannot
>>>     exceed, the new runner has a timeout on inactivity. Activity is
>>>     any output on the test's stdout or stderr, or kernel activity via
>>>     /dev/kmsg.
>>
>> Is there going to be also a (longer) timeout on execution time? It would
>> help if a test is stuck in a loop (e.g. retrying on EAGAIN forever) and is
>> therefore responsive but just not progressing forward.
> 
> What timeout values are used in CI and in which way is still up in the
> air. With an inactivity timeout (as implemented here) we can have
> individual tests that run for more than the 10 minutes that piglit
> enforces (as long as they seem alive), and have timeouts earlier for
> tests that don't seem active. Other possibilities (in addition to
> inactivity timeout) are overall timeouts for "full execution of this
> test list should take 15 minutes total, tops", or having a cap for an
> individual subtest, an individual binary (all subtests it's going to
> run in this execution), and combine those with expanding the testlist
> format to specify the caps based on real data. Meaning,

I would prefer a large per-subtest execution timeout paired with a small 
inactivity timeout. Where the values of large and small would probably 
have to be chosen empirically. This way a 'bad' test would fail still 
but not affect the results from other tests in the same run.

> 
> igt@foobar@frob-some 60

Could this be auto-generated from somewhere?

Thanks,
Antonio

> 
> would kill that process after 60 seconds.
> 
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2018-06-14 20:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-13 10:07 [igt-dev] [PATCH i-g-t v2 0/5] New runner to rule them all, version 2 Petri Latvala
2018-06-13 10:07 ` [igt-dev] [PATCH i-g-t v2 1/5] lib: Print subtest starting/ending line to stderr too Petri Latvala
2018-06-13 10:07 ` [igt-dev] [PATCH i-g-t 2/5] lib: Export igt_gettime and igt_time_elapsed Petri Latvala
2018-06-13 10:07 ` [igt-dev] [PATCH i-g-t 3/5] uwildmat: Case-insensitive test selection Petri Latvala
2018-06-13 10:07 ` [igt-dev] [PATCH i-g-t v2 4/5] runner: New test runner Petri Latvala
2018-06-13 10:20   ` Chris Wilson
2018-06-13 10:50     ` Petri Latvala
2018-06-13 17:10   ` Antonio Argenziano
2018-06-14 10:18     ` Petri Latvala
2018-06-14 20:14       ` Antonio Argenziano [this message]
2018-06-15  8:53         ` Petri Latvala
2018-06-18 11:14           ` Joonas Lahtinen
2018-07-25 11:56   ` Arkadiusz Hiler
2018-07-25 12:41     ` Chris Wilson
2018-06-13 10:07 ` [igt-dev] [PATCH i-g-t v2 5/5] runner: Unit tests for the runner Petri Latvala
2018-06-13 10:17   ` [igt-dev] [PATCH i-g-t v3 1/1] " Petri Latvala
2018-06-13 10:09 ` [igt-dev] ✗ Fi.CI.BAT: failure for New runner to rule them all, version 2 Patchwork
2018-06-13 11:14 ` Patchwork
2018-06-13 11:35 ` Patchwork

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=c11c99ee-d5f9-46e4-9d63-a03c4d217a19@intel.com \
    --to=antonio.argenziano@intel.com \
    --cc=igt-dev@lists.freedesktop.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.