Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Senna Tschudin <peter.senna@linux.intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>,
	"vitaly prosyak" <vprosyak@amd.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: Wed, 26 Feb 2025 10:43:08 +0100	[thread overview]
Message-ID: <9c5d27e4-12b2-4597-97cd-da72bc07d1dc@linux.intel.com> (raw)
In-Reply-To: <20250226090958.32igx6wiy4svxw3h@zkempczy-mobl2>

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.

Vitaly, can you confirm if -kfile would work for your use case? I'm
happy to adjust the implementation to better fit your needs.

Thank you,

Peter



> 
> --
> Zbigniew
> 
>>
>> On 2025-02-19 05:41, Kamil Konieczny wrote:
>>> Hi Vitaly,
>>> On 2025-02-18 at 06:43:41 -0500, vitaly.prosyak@amd.com wrote:
>>>> From: Vitaly Prosyak <vitaly.prosyak@amd.com>
>>>>
>>>> refactor memory leak functions and add
>>>> them to the library for reuse across different tests.
>>>>
>>>> Cc: Christian Koenig <christian.koenig@amd.com>
>>>> Cc: Alexander Deucher <alexander.deucher@amd.com>
>>>> Cc: Jesse Zhang <jesse.zhang@amd.com>
>>>> Cc: Harry Wentland <harry.wentland@amd.com>
>>>>
>>>> Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
>>>> ---
>>>>  lib/amdgpu/amd_mem_leak.c   | 112 ++++++++++++++++++++++++++++++++++++
>>>>  lib/amdgpu/amd_mem_leak.h   |  17 ++++++
>>>>  lib/meson.build             |   1 +
>>>>  tests/amdgpu/amd_mem_leak.c |  88 ++--------------------------
>>>>
>>> [...cut...]
>>>
>>> Why moving to library when there is only one user?
>>>
>>> Regards,
>>> Kamil
>>>


  reply	other threads:[~2025-02-26  9:43 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 [this message]
2025-02-26 10:09         ` Zbigniew Kempczyński
2025-02-26 10:24           ` Peter Senna Tschudin
2025-02-27  5:08             ` vitaly prosyak
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=9c5d27e4-12b2-4597-97cd-da72bc07d1dc@linux.intel.com \
    --to=peter.senna@linux.intel.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=vitaly.prosyak@amd.com \
    --cc=vprosyak@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