All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: igt-dev@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: [igt-dev] [PATCH i-g-t] tests/i915/gem_exec_params: check available memory earlier
Date: Tue,  1 Mar 2022 11:03:59 +0000	[thread overview]
Message-ID: <20220301110359.663637-1-matthew.auld@intel.com> (raw)

The shmem mmap and pwrite interfaces conveniently let us probe just a
few pages, without needing to populate the entire object. On discrete
and newer platforms the kernel has dropped support for both, leaving us
with MMAP_OFFSET, which will always populate the entire object, for now
at least. Luckily we can just move the batch creation to after checking
the available memory to ensure we don't hit -ENOMEM on such platforms.

Also it seems that doing a massive allocation(filling much of system
memory) and then calling intel_purge_vm_caches() seems to take 40+
seconds, like when calling intel_require_memory(). Hence switching the
ordering here should also help with that.

For reference the larger-than-life test is just a simple regression test
to ensure that some very large batch buffer(greater than ~4G) can't
overflow the batch_len, causing all kinds of issues. See 57b2d834bf23
("drm/i915/gem: Support parsing of oversize batches").

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
---
 tests/i915/gem_exec_params.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index d247b8a6..da36af74 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -332,9 +332,7 @@ static void test_larger_than_life_batch(int fd)
 	const struct intel_execution_engine2 *e;
 	uint64_t size = 1ULL << 32; /* batch_len is __u32 as per the ABI */
 	const intel_ctx_t *ctx = intel_ctx_create_all_physical(fd);
-	struct drm_i915_gem_exec_object2 exec = {
-		.handle = batch_create_size(fd, size),
-	};
+	struct drm_i915_gem_exec_object2 exec = {};
 	struct drm_i915_gem_execbuffer2 execbuf = {
 		.buffers_ptr = to_user_pointer(&exec),
 		.buffer_count = 1,
@@ -350,6 +348,8 @@ static void test_larger_than_life_batch(int fd)
 	igt_require(size < gem_aperture_size(fd));
 	intel_require_memory(2, size, CHECK_RAM); /* batch + shadow */
 
+	exec.handle = batch_create_size(fd, size);
+
 	for_each_ctx_engine(fd, ctx, e) {
 		/* Keep the batch_len implicit [0] */
 		execbuf.flags = e->flags;
-- 
2.34.1

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Auld <matthew.auld@intel.com>
To: igt-dev@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH i-g-t] tests/i915/gem_exec_params: check available memory earlier
Date: Tue,  1 Mar 2022 11:03:59 +0000	[thread overview]
Message-ID: <20220301110359.663637-1-matthew.auld@intel.com> (raw)

The shmem mmap and pwrite interfaces conveniently let us probe just a
few pages, without needing to populate the entire object. On discrete
and newer platforms the kernel has dropped support for both, leaving us
with MMAP_OFFSET, which will always populate the entire object, for now
at least. Luckily we can just move the batch creation to after checking
the available memory to ensure we don't hit -ENOMEM on such platforms.

Also it seems that doing a massive allocation(filling much of system
memory) and then calling intel_purge_vm_caches() seems to take 40+
seconds, like when calling intel_require_memory(). Hence switching the
ordering here should also help with that.

For reference the larger-than-life test is just a simple regression test
to ensure that some very large batch buffer(greater than ~4G) can't
overflow the batch_len, causing all kinds of issues. See 57b2d834bf23
("drm/i915/gem: Support parsing of oversize batches").

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
---
 tests/i915/gem_exec_params.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index d247b8a6..da36af74 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -332,9 +332,7 @@ static void test_larger_than_life_batch(int fd)
 	const struct intel_execution_engine2 *e;
 	uint64_t size = 1ULL << 32; /* batch_len is __u32 as per the ABI */
 	const intel_ctx_t *ctx = intel_ctx_create_all_physical(fd);
-	struct drm_i915_gem_exec_object2 exec = {
-		.handle = batch_create_size(fd, size),
-	};
+	struct drm_i915_gem_exec_object2 exec = {};
 	struct drm_i915_gem_execbuffer2 execbuf = {
 		.buffers_ptr = to_user_pointer(&exec),
 		.buffer_count = 1,
@@ -350,6 +348,8 @@ static void test_larger_than_life_batch(int fd)
 	igt_require(size < gem_aperture_size(fd));
 	intel_require_memory(2, size, CHECK_RAM); /* batch + shadow */
 
+	exec.handle = batch_create_size(fd, size);
+
 	for_each_ctx_engine(fd, ctx, e) {
 		/* Keep the batch_len implicit [0] */
 		execbuf.flags = e->flags;
-- 
2.34.1


             reply	other threads:[~2022-03-01 11:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01 11:03 Matthew Auld [this message]
2022-03-01 11:03 ` [Intel-gfx] [PATCH i-g-t] tests/i915/gem_exec_params: check available memory earlier Matthew Auld
2022-03-01 11:57 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2022-03-01 18:37 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2022-03-01 22:24 ` [igt-dev] [PATCH i-g-t] " Dixit, Ashutosh
2022-03-01 22:24   ` [Intel-gfx] " Dixit, Ashutosh

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=20220301110359.663637-1-matthew.auld@intel.com \
    --to=matthew.auld@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.