From: Jani Nikula <jani.nikula@intel.com>
To: "Knop, Ryszard" <ryszard.knop@intel.com>,
"igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
"kamil.konieczny@linux.intel.com"
<kamil.konieczny@linux.intel.com>
Cc: "Kempczynski, Zbigniew" <zbigniew.kempczynski@intel.com>,
"Thomas, Sobin" <sobin.thomas@intel.com>
Subject: Re: [PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test
Date: Fri, 29 May 2026 15:52:13 +0300 [thread overview]
Message-ID: <425e70c4ff7133d6101ed0e52902aa3d73dc3dc1@intel.com> (raw)
In-Reply-To: <5a9494611b1644f3113d6972e55103e3aeead1fa.camel@intel.com>
On Fri, 29 May 2026, "Knop, Ryszard" <ryszard.knop@intel.com> wrote:
> IMO this is going to end up either unused, and people will keep
> complaining they want a higher limit anyways, or overused, and people
> will complain why some of their logs are randomly missing from CI logs.
>
> In general it seems like this does not break the CI infra directly, so
> I won't say no to anything here, but it's one of those things that dial
> up the magic and we seem to have lots of that in disk limits recently.
Overall seems like there are a number of hacky approaches being added,
e.g. tweaking of the drm.debug parameter value, and filtering parts of
the dmesg.
Debugging issues is often seriously difficult even with the full
dmesg. Having an imcomplete dmesg makes everything more difficult. And
it's the worst if you don't even know that when looking at the dmesg.
We could *maybe* discuss reducing the stored dmesgs for tests that
passed. Or reduce the time the dmesgs are stored for passed dmesgs. But
even then it's often useful to see the passed results when debugging
failed results.
But no matter what, full dmesgs should be the standard for failed tests,
and nothing less is acceptable.
BR,
Jani.
>
> Ryszard
>
> On Wed, 2026-05-20 at 17:49 +0200, Kamil Konieczny wrote:
>> Inform igt_runner about some lines in dmesg which could be
>> safely skipped during creating a results.json.
>>
>> With this, runner will also lift dmesg size limit for current
>> test and will postpone size fitting to last phase of a run when
>> it will generate json report.
>>
>> TODO: This is draft which implements only lines skipping, without
>> any reporting what was done. Also, implementation for a fail path
>> when applied regex will not lower resulting demsg is left for
>> future.
>>
>> Cc: Sobin Thomas <sobin.thomas@intel.com>
>> Cc: Ryszard Knop <ryszard.knop@intel.com>
>> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
>>
>> Kamil Konieczny (4):
>> runner/executor: Create temporary unlimited dmesg save
>> lib/igt_core: Create message for runner with unlimiting dmesg size
>> tests/intel/xe_exec_system_allocator: Lower dmesg size collected
>> runner/resultgen: Create smaller dmesg report by dropping lines
>> matched with skip regex
>>
>> lib/igt_core.c | 31 +++++++++++++++++++
>> lib/igt_core.h | 1 +
>> runner/executor.c | 43 ++++++++++++++++----------
>> runner/output_strings.h | 8 +++++
>> runner/resultgen.c | 17 ++++++++--
>> tests/intel/xe_exec_system_allocator.c | 1 +
>> 6 files changed, 83 insertions(+), 18 deletions(-)
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-05-29 12:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 15:49 [PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test Kamil Konieczny
2026-05-20 15:49 ` [PATCH i-g-t v1 1/4] runner/executor: Create temporary unlimited dmesg save Kamil Konieczny
2026-05-20 15:49 ` [PATCH i-g-t v1 2/4] lib/igt_core: Create message for runner with unlimiting dmesg size Kamil Konieczny
2026-05-20 15:49 ` [PATCH i-g-t v1 3/4] tests/intel/xe_exec_system_allocator: Lower dmesg size collected Kamil Konieczny
2026-05-20 15:49 ` [PATCH i-g-t v1 4/4] runner/resultgen: Create smaller dmesg report by dropping lines matched with skip regex Kamil Konieczny
2026-05-29 12:06 ` [PATCH i-g-t v1 0/4] RFC: Create smaller dmesg reports for a test Knop, Ryszard
2026-05-29 12:52 ` Jani Nikula [this message]
2026-05-29 15:09 ` Ville Syrjälä
2026-05-29 15:51 ` Knop, Ryszard
2026-05-29 21:07 ` Kamil Konieczny
2026-05-29 21:04 ` Kamil Konieczny
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=425e70c4ff7133d6101ed0e52902aa3d73dc3dc1@intel.com \
--to=jani.nikula@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=kamil.konieczny@linux.intel.com \
--cc=ryszard.knop@intel.com \
--cc=sobin.thomas@intel.com \
--cc=zbigniew.kempczynski@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox