From: vitaly prosyak <vprosyak@amd.com>
To: "Peter Senna Tschudin" <peter.senna@linux.intel.com>,
"Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
vitaly.prosyak@amd.com, igt-dev@lists.freedesktop.org,
Christian Koenig <christian.koenig@amd.com>,
Alexander Deucher <alexander.deucher@amd.com>,
Jesse Zhang <jesse.zhang@amd.com>,
Harry Wentland <harry.wentland@amd.com>
Subject: Re: [PATCH] lib/amd: add memleak functions
Date: Thu, 27 Feb 2025 00:08:19 -0500 [thread overview]
Message-ID: <2a494d9e-d771-4bd6-b328-517b7cc7dc50@amd.com> (raw)
In-Reply-To: <1ec35fc8-92a5-4e69-a562-142745f59659@linux.intel.com>
On 2025-02-26 05:24, Peter Senna Tschudin wrote:
>
> On 26.02.2025 11:09, Zbigniew Kempczyński wrote:
>> On Wed, Feb 26, 2025 at 10:43:08AM +0100, Peter Senna Tschudin wrote:
>>> Hello Vitaly,
>>>
>>> On 26.02.2025 10:09, Zbigniew Kempczyński wrote:
>>>> On Wed, Feb 19, 2025 at 12:50:49PM -0500, vitaly prosyak wrote:
>>>>> Hi Kamil,
>>>>>
>>>>> Thanks for raising this question. Currently, only a single test uses the memleak feature. However, we are planning to add more. This effort requires careful selection, as we want to avoid unnecessary overhead or burden. Enabling the memleak configuration significantly slows down test execution—potentially increasing the duration by 2-3 times.
>>>>>
>>>>> Additionally, we aim to reach internal consensus on which tests should have this feature enabled. We also want to avoid enabling both KASAN and memleak simultaneously. These considerations are the reason for the delay.
>>>>>
>>>>> Thanks for your understanding!
>>>>>
>>>>> Vitaly
>>>> +Peter
>>>>
>>>> Peter proposed solution which is global and vendor agnostic. I mean
>>>> his changes https://patchwork.freedesktop.org/series/143996/
>>>> allow you to selectively run with kmemleak on using runner (-k).
>>>> Together with proper list selection passed to the runner you're
>>>> able to run only tests which you want to check for memory leaks.
>>> Thank you, Zbigniew! Just to clarify, my patch currently supports:
>>> -konce, which collects a single kmemleak log after all tests have run.
>>> -keach, which collects kmemleak logs after each test.
>>>
>>> However, after reading this discussion, I came up with a proposal for a
>>> new option: -kfile. With this mode, igt_runner will collect kmemleak
>>> logs only after running the tests specified in a given text file.
>> You don't need this, testlist is your file.
> Yes, indeed. A test list + -keach does it. Vitaly would you comment about
> the current approach in the context of your needs?
Hi Peter,
Thanks for the update! I really appreciate the effort you’ve put into making the approach more global and vendor-agnostic—great work!
It would be incredibly useful to have both --kmemleak options available (for the entire test list and individual tests).
Could you kindly provide guidance on how to add these options (-konce or -keach) to igt-runner? For example, how should I modify the following commands to include them?
sudo ./scripts/run-tests.sh -t -v /home/vprosyak/src/igt-gpu-tools/build/tests/amd/amd_basic
or
sudo ./scripts/run-tests.sh -v -T /home/infra/igt/custom.testlist
Thanks again for your great work and support!
Vitaly
> [...]
next prev parent reply other threads:[~2025-02-27 5:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 11:43 [PATCH] lib/amd: add memleak functions vitaly.prosyak
2025-02-18 13:15 ` ✓ i915.CI.BAT: success for " Patchwork
2025-02-18 14:16 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-18 18:10 ` ✗ i915.CI.Full: failure " Patchwork
2025-02-19 1:16 ` [PATCH] " Zhang, Jesse(Jie)
2025-02-19 4:49 ` ✗ Xe.CI.Full: failure for " Patchwork
2025-02-19 10:41 ` [PATCH] " Kamil Konieczny
2025-02-19 17:50 ` vitaly prosyak
2025-02-26 9:09 ` Zbigniew Kempczyński
2025-02-26 9:43 ` Peter Senna Tschudin
2025-02-26 10:09 ` Zbigniew Kempczyński
2025-02-26 10:24 ` Peter Senna Tschudin
2025-02-27 5:08 ` vitaly prosyak [this message]
2025-02-27 9:08 ` Peter Senna Tschudin
2025-02-27 10:53 ` Kamil Konieczny
2025-02-27 11:13 ` Peter Senna Tschudin
2025-02-28 3:01 ` vitaly prosyak
2025-02-27 10:27 ` Peter Senna Tschudin
2025-02-28 3:17 ` vitaly prosyak
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=2a494d9e-d771-4bd6-b328-517b7cc7dc50@amd.com \
--to=vprosyak@amd.com \
--cc=alexander.deucher@amd.com \
--cc=christian.koenig@amd.com \
--cc=harry.wentland@amd.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=jesse.zhang@amd.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=peter.senna@linux.intel.com \
--cc=vitaly.prosyak@amd.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