From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
To: Krzysztof Karas <krzysztof.karas@intel.com>,
<intel-gfx@lists.freedesktop.org>
Cc: Matthew Auld <matthew.auld@intel.com>,
Andi Shyti <andi.shyti@linux.intel.com>,
Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Subject: Re: [PATCH] drm/i915/selftests: Keep mock file open during unfaultable migrate with fill
Date: Tue, 10 Jun 2025 12:55:10 +0000 [thread overview]
Message-ID: <DAIVAR1Z6FC9.3BFLJGCGDX1T3@intel.com> (raw)
In-Reply-To: <rkhynu6kvc66vebupjvz6wah4qlxcbbxpnesjx2njqsfhxtk2n@rotnqdv2ori4>
On Tue Jun 10, 2025 at 10:21 AM UTC, Krzysztof Karas wrote:
> igt_mmap_migrate() tests migration with various parameters.
> In one of the cases, where FILL and UNFAULTABLE flags are set,
> during first stages of this test a mock file is opened in
> igt_mmap_offset(), which results in allocating some data in the
> GPU memory. Then, also in igt_mmap_offset(), the file is closed
> (fput) and the cleanup of that data is scheduled. Right after
> that, the test calls igt_fill_mappable() to fill all available
> GPU memory. At this point, three scenarios are possible
> (N = max size of GPU memory for this test in MiB):
> 1) the data cleanup does not fire until the whole test is over,
> so the memory is fully occupied by 1 MiB with that data and
> N - 1 MiB added by igt_fill_mappable(),
> 2) the data cleanup fires before igt_fill_mappable() completes,
> so the whole memory is populated with N MiB by
> igt_fill_mappable(),
> 3) the data cleanup is performed right after fill is done,
> so only N - 1 MiB are in the GPU memory, preventing the test
> from properly faulting - we'd expect no space left, but an
> object was able to fit in the remaining 1 MiB.
>
> Amend the problem by keeping the mock file open throughout the
> duration of this test and calling fput() from the test itself.
>
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13929
> Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
> ---
>
> On DG2 platforms the memory for data allocated as a result of
> opening a mock file remains occupied until the test is done
> (scenario 1), but on ATSM cards the data is freed earlier
> (scenarios 2 and 3), which leads to sporadic failures.
>
> During testing I observed that the max memory was equal
> to either 4096 or 2048 and igt_fill_mappable() tries to allocate
> as many 1k objects as possible before halving allocation size.
>
> .../drm/i915/gem/selftests/i915_gem_mman.c | 6 ++-
> drivers/gpu/drm/i915/selftests/igt_mmap.c | 54 +++++++++++++------
> drivers/gpu/drm/i915/selftests/igt_mmap.h | 8 +++
> 3 files changed, 51 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> index 9c3f17e51885..1fe4a45d3efb 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> @@ -1176,6 +1176,7 @@ static int __igt_mmap_migrate(struct intel_memory_region **placements,
> struct drm_i915_private *i915 = placements[0]->i915;
> struct drm_i915_gem_object *obj;
> struct i915_request *rq = NULL;
> + struct file *mock_file;
> unsigned long addr;
> LIST_HEAD(objects);
> u64 offset;
> @@ -1200,8 +1201,8 @@ static int __igt_mmap_migrate(struct intel_memory_region **placements,
> * level paging structures(and perhaps scratch), so make sure we
> * allocate early, to avoid tears.
> */
> - addr = igt_mmap_offset(i915, offset, obj->base.size,
> - PROT_WRITE, MAP_SHARED);
> + addr = igt_mmap_offset_get_file(i915, offset, obj->base.size,
> + PROT_WRITE, MAP_SHARED, &mock_file);
> if (IS_ERR_VALUE(addr)) {
> err = addr;
> goto out_put;
> @@ -1299,6 +1300,7 @@ static int __igt_mmap_migrate(struct intel_memory_region **placements,
> }
>
> out_put:
> + fput(mock_file);
> i915_gem_object_put(obj);
> igt_close_objects(i915, &objects);
> return err;
> diff --git a/drivers/gpu/drm/i915/selftests/igt_mmap.c b/drivers/gpu/drm/i915/selftests/igt_mmap.c
> index e920a461bd36..237ad91cd009 100644
> --- a/drivers/gpu/drm/i915/selftests/igt_mmap.c
> +++ b/drivers/gpu/drm/i915/selftests/igt_mmap.c
> @@ -9,14 +9,14 @@
> #include "i915_drv.h"
> #include "igt_mmap.h"
>
> -unsigned long igt_mmap_offset(struct drm_i915_private *i915,
> - u64 offset,
> - unsigned long size,
> - unsigned long prot,
> - unsigned long flags)
> +static unsigned long __igt_mmap_offset(struct drm_i915_private *i915,
> + u64 offset,
> + unsigned long size,
> + unsigned long prot,
> + unsigned long flags,
> + struct file **file)
> {
> struct drm_vma_offset_node *node;
> - struct file *file;
> unsigned long addr;
> int err;
>
> @@ -32,21 +32,45 @@ unsigned long igt_mmap_offset(struct drm_i915_private *i915,
> }
>
> /* Pretend to open("/dev/dri/card0") */
> - file = mock_drm_getfile(i915->drm.primary, O_RDWR);
> - if (IS_ERR(file))
> - return PTR_ERR(file);
> + *file = mock_drm_getfile(i915->drm.primary, O_RDWR);
> + if (IS_ERR(*file))
> + return PTR_ERR(*file);
>
> - err = drm_vma_node_allow(node, file->private_data);
> + err = drm_vma_node_allow(node, (*file)->private_data);
> if (err) {
> - addr = err;
> - goto out_file;
> + fput(*file);
I'll try to avoid calling fput() here and instead handle it where the
file is created. This will simplify tracking the file's lifecycle.
--
Best regards,
Sebastian
next prev parent reply other threads:[~2025-06-10 12:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 10:21 [PATCH] drm/i915/selftests: Keep mock file open during unfaultable migrate with fill Krzysztof Karas
2025-06-10 11:42 ` Krzysztof Niemiec
2025-06-11 7:37 ` Krzysztof Karas
2025-06-10 11:54 ` ✓ i915.CI.BAT: success for " Patchwork
2025-06-10 12:55 ` Sebastian Brzezinka [this message]
2025-06-11 7:39 ` [PATCH] " Krzysztof Karas
2025-06-10 13:57 ` ✗ i915.CI.Full: failure for " Patchwork
2025-06-11 10:40 ` [PATCH] " Chris Wilson
2025-06-11 14:22 ` kernel test robot
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=DAIVAR1Z6FC9.3BFLJGCGDX1T3@intel.com \
--to=sebastian.brzezinka@intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=krzysztof.karas@intel.com \
--cc=krzysztof.niemiec@intel.com \
--cc=matthew.auld@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.