Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Senna Tschudin <peter.senna@linux.intel.com>
To: igt-dev@lists.freedesktop.org
Cc: Peter Senna Tschudin <peter.senna@linux.intel.com>,
	ryszard.knop@intel.com, lucas.demarchi@intel.com,
	katarzyna.piecielska@intel.com, jonathan.cavitt@intel.com
Subject: [PATCH i-g-t v4 0/2] Integrate kmemleak scans in igt_runner
Date: Tue, 28 Jan 2025 16:15:35 +0100	[thread overview]
Message-ID: <20250128151537.515639-1-peter.senna@linux.intel.com> (raw)

This patch series introduces a library to interact with the Linux
kernel's kmemleak feature and integrates it into igt_runner. If
kmemleaks are detected, they will be saved in the igt_runner results
directory in a file named kmemleak.txt.

During testing, the size of the kmemleak.txt file varied significantly.
Larger files, up to 2 MB, were observed when running i915-BAT on a
Tiger Lake DUT. Conversely, smaller files, typically under 100 KB, were
generated when running Xe BAT on the same DUT.

Large files often contain numerous false positives, with the e1000
driver being a frequent source of noise. The time required for the
Linux kernel to complete a kmemleak scan ranges from 5 to 60 seconds.
This variability can cause igt_runner to slow down by a factor of 4
when using the -keach option.

Transient leaks are a common phenomenon but are mostly undetected by
the current version of this library. A typical transient leak occurs
when pointers are reused, such as in linked lists. For example, if 10
calls to kmalloc are made, storing the address in the same variable
and freeing only the final allocation, the previous 9 allocations
become transient leaks. These leaks will go undetected unless the
kernel thread performs continuous scanning.

To enable continuous scanning:
 # echo scan=1 > /sys/kernel/debug/kmemleak

This configures the kmemleak kernel thread to scan the memory
continuously with 1 second pauses. While this may increase the
likelihood of detecting transient leaks, it can significantly impact
system performance. In most cases, the igt_runner slowdown remains in
the 4x range, but the kernel thread will consume 100% of a CPU core,
as observed with tools like top.

When using scan=1, transient leaks that exist during an active scan
will be detected. However, detection remains non-deterministic due
to timing. It is recommended to reset the scan interval to the
default value of 600 seconds after completing your tests.

v4:
 - Cleaned-up CC list
 - Fixed typo in patch numbering
 - Fixed Reviewed-by tag
 - Reintroduced ',' after "results-path". It was removed by accident
 - Changed unit testing for calling igt_kmemleak() with and without
   sync.

v3:
 - Removed '>' from the end of one of the email addresses in the cc list
 - Removed email addresses that no longer exist

v2:
 - Pass igt_kmemleak_sync as a function variable to igt_kmemleak instead of
   keeping it stored as a global variable
 - igt_kmemleak_found_leaks(): Remove call to fseek() after close()
 - igt_kmemleak_write(): Increase retry counter when writing 0 bytes
 - igt_kmemleak_write(): change type to bool
 - Unit Testing: Move the call to igt_kmemleak_init() to a fixture.
 - igt_kmemleak_append_to(): Add brackets to the if statement for improved
   readability

CC: ryszard.knop@intel.com
CC: lucas.demarchi@intel.com
CC: katarzyna.piecielska@intel.com
CC: jonathan.cavitt@intel.com

Peter Senna Tschudin (2):
  lib/igt_kmemleak: library to interact with kmemleak
  runner/executor: Integrate igt_kmemleak scans

 lib/igt_kmemleak.c       | 274 +++++++++++++++++++++++++++++++++++++++
 lib/igt_kmemleak.h       |  16 +++
 lib/meson.build          |   1 +
 lib/tests/igt_kmemleak.c | 267 ++++++++++++++++++++++++++++++++++++++
 lib/tests/meson.build    |   1 +
 runner/executor.c        |  25 +++-
 runner/runner_tests.c    |  16 ++-
 runner/settings.c        |  31 ++++-
 runner/settings.h        |   2 +
 9 files changed, 629 insertions(+), 4 deletions(-)
 create mode 100644 lib/igt_kmemleak.c
 create mode 100644 lib/igt_kmemleak.h
 create mode 100644 lib/tests/igt_kmemleak.c

-- 
2.34.1


             reply	other threads:[~2025-01-28 15:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 15:15 Peter Senna Tschudin [this message]
2025-01-28 15:15 ` [PATCH i-g-t v4 1/2] lib/igt_kmemleak: library to interact with kmemleak Peter Senna Tschudin
2025-01-31 12:34   ` Kamil Konieczny
2025-02-03  9:23     ` Peter Senna Tschudin
2025-02-11 16:17       ` Zbigniew Kempczyński
2025-02-11 19:12         ` Peter Senna Tschudin
2025-02-12  8:36           ` Zbigniew Kempczyński
2025-02-12  9:18             ` Peter Senna Tschudin
2025-02-12 10:01               ` Zbigniew Kempczyński
2025-02-12 13:12                 ` Peter Senna Tschudin
2025-02-12 13:41                   ` Kamil Konieczny
2025-02-12 14:57                     ` Peter Senna Tschudin
2025-02-25 13:46         ` Peter Senna Tschudin
2025-02-25 18:06           ` Peter Senna Tschudin
2025-01-31 12:38   ` Kamil Konieczny
2025-02-03  9:14     ` Peter Senna Tschudin
2025-02-12 14:26       ` Kamil Konieczny
2025-01-28 15:15 ` [PATCH i-g-t v4 2/2] runner/executor: Integrate igt_kmemleak scans Peter Senna Tschudin
2025-01-31 12:50   ` Kamil Konieczny
2025-02-03  9:10     ` Peter Senna Tschudin
2025-02-12 14:24       ` Kamil Konieczny
2025-02-12 14:53         ` Peter Senna Tschudin
2025-01-28 20:48 ` ✓ i915.CI.BAT: success for Integrate kmemleak scans in igt_runner (rev2) Patchwork
2025-01-28 20:49 ` Patchwork
2025-01-28 20:52 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-29 10:40 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-29 13:18   ` Peter Senna Tschudin
2025-01-29 11:25 ` ✗ i915.CI.Full: " Patchwork
2025-01-29 13:19   ` Peter Senna Tschudin
2025-01-30  6:18     ` Ravali, JupallyX
2025-01-30  5:26 ` ✓ i915.CI.Full: success " 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=20250128151537.515639-1-peter.senna@linux.intel.com \
    --to=peter.senna@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jonathan.cavitt@intel.com \
    --cc=katarzyna.piecielska@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=ryszard.knop@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