Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Petri Latvala <petri.latvala@intel.com>
To: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t 2/2] runner: Introduce --disk-usage-limit
Date: Thu, 18 Jun 2020 15:49:07 +0300	[thread overview]
Message-ID: <20200618124907.GI20883@platvala-desk.ger.corp.intel.com> (raw)
In-Reply-To: <20200618122628.pdpptfx7idljgr6v@ahiler-desk1.fi.intel.com>

On Thu, Jun 18, 2020 at 03:26:28PM +0300, Arkadiusz Hiler wrote:
> On Thu, Jun 18, 2020 at 03:06:23PM +0300, Petri Latvala wrote:
> > Disk usage limit is a limit of disk space taken, per (dynamic)
> > subtest. If the test's output, kernel log included, exceeds this
> > limit, the test is killed, similarly to killing the test when the
> > kernel gets tainted.
> 
> So this is a combined limit, i.e. shared by stderr, stdout and dmesg,
> right?

Yes, combined limit.

> Also since this is handled by need_to_timeout, will the final test
> result be a timeout?

It will be an incomplete. With an injection in the stdout, like when
killing for taints, for automatic filtering.

> Any particular reason why we are killing the test instead of just
> appending a message that output was truncated and letting the test be?
> 
> When we were talking about this I had imagined something more like:
> 
>  1. size limit per logged file
>  2. test finishes execution
>  3. the logs state that the test was spammy and we truncated the logs
>  4. "promote" passes to warns in such cases
> 
> No strong feeling on which option we will go with, but I would like to
> understand why you went in that way.

In my opinion it's a waste of disk space on the DUT; There shouldn't
be a case where having "too much" (tm) stuff logged is considered
normal. And if we accept that, we might as well also save some time by
killing the test when we go over.

Truncating the logs is possible but way more code; Instead of just
finding the delimit offsets in the stdout file and stuffing that range
to the json string object, you need to construct a new string, making
sure you avoid cutting out the subtest result line. I repeat:
Possible, almost easy. Just more code in an already complex resultgen
codebase for doing a simple thing :P

So in a nutshell: The approach depends on whether spamming logs is
considered "just a warn" or "oh, please no".


-- 
Petri Latvala
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2020-06-18 12:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-18 12:06 [igt-dev] [PATCH i-g-t 1/2] runner: Inject a message when killing test to taints Petri Latvala
2020-06-18 12:06 ` [igt-dev] [PATCH i-g-t 2/2] runner: Introduce --disk-usage-limit Petri Latvala
2020-06-18 12:26   ` Arkadiusz Hiler
2020-06-18 12:49     ` Petri Latvala [this message]
2020-06-18 12:52       ` Arkadiusz Hiler
2020-06-18 12:26 ` [igt-dev] [PATCH i-g-t 1/2] runner: Inject a message when killing test to taints Arkadiusz Hiler
2020-06-18 13:24 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/2] " Patchwork
2020-06-18 13:29   ` Petri Latvala
2020-06-18 14:22 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2020-06-18 15:32 ` [igt-dev] ✗ GitLab.Pipeline: warning " 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=20200618124907.GI20883@platvala-desk.ger.corp.intel.com \
    --to=petri.latvala@intel.com \
    --cc=arkadiusz.hiler@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox