Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cavitt <jonathan.cavitt@intel.com>
To: igt-dev@lists.freedesktop.org
Cc: jonathan.cavitt@intel.com, nirmoy.das@intel.com
Subject: [igt-dev] [PATCH i-g-t 1/1] lib/intel_allocator: Limit last page if not reserved
Date: Tue, 19 Sep 2023 10:02:30 -0700	[thread overview]
Message-ID: <20230919170230.3307408-2-jonathan.cavitt@intel.com> (raw)
In-Reply-To: <20230919170230.3307408-1-jonathan.cavitt@intel.com>

We currently limit the last page of the allocator space to avoid a hang
on some platforms when a batch would be pinned in the last page.
However, in the future, we may already be reserving the last page of the
ppgtt in kernel space, so we would not need to limit the last page
because gem_aperture_size would not report its existence in
__intel_allocator_open_full when this is the case.

Check the gtt_size and only limit the last page if it's not already
reserved by kernel space.  This is generalized to if the reported page
count is even.

Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
---
 lib/intel_allocator.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/lib/intel_allocator.c b/lib/intel_allocator.c
index f0a9b7fb53..fc7836dcee 100644
--- a/lib/intel_allocator.c
+++ b/lib/intel_allocator.c
@@ -53,12 +53,6 @@ static inline const char *reqstr(enum reqtype request_type)
 #define bind_debug(...) {}
 #endif
 
-/*
- * We limit allocator space to avoid hang when batch would be
- * pinned in the last page.
- */
-#define RESERVED 4096
-
 struct allocator {
 	int fd;
 	uint32_t ctx;
@@ -941,11 +935,21 @@ static uint64_t __intel_allocator_open_full(int fd, uint32_t ctx,
 		if (!end) {
 			igt_assert_f(can_report_gtt_size(fd), "Invalid fd\n");
 			gtt_size = gem_aperture_size(fd);
-			if (!gem_uses_full_ppgtt(fd))
+			if (!gem_uses_full_ppgtt(fd)) {
 				gtt_size /= 2;
-			else
-				gtt_size -= RESERVED;
-
+			} else {
+				/*
+				 * We limit allocator space to avoid hang when batch would be
+				 * pinned in the last page.
+				 *
+				 * The last page is reserved when the gtt_size is aligned
+				 * with an odd number of pages.
+				 */
+				uint64_t align = gtt_size % (SZ_4K * 2);
+				align += SZ_4K;
+				align %= (SZ_4K * 2);
+				gtt_size -= align;
+			}
 			req.open.end = gtt_size;
 		}
 
-- 
2.25.1

  reply	other threads:[~2023-09-19 17:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19 17:02 [igt-dev] [PATCH i-g-t 0/1] lib/intel_allocator: Limit last page if not reserved Jonathan Cavitt
2023-09-19 17:02 ` Jonathan Cavitt [this message]
2023-09-19 19:06   ` [igt-dev] [PATCH i-g-t 1/1] " Zbigniew Kempczyński
2023-09-19 18:07 ` [igt-dev] ✓ CI.xeBAT: success for " Patchwork
2023-09-19 18:17 ` [igt-dev] ✗ Fi.CI.BAT: failure " 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=20230919170230.3307408-2-jonathan.cavitt@intel.com \
    --to=jonathan.cavitt@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=nirmoy.das@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