From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Matthew Brost <matthew.brost@intel.com>,
"Zeng, Oak" <oak.zeng@intel.com>
Subject: Separating xe_vma- and page-table state
Date: Tue, 12 Mar 2024 08:43:05 +0100 [thread overview]
Message-ID: <72ea6bc36260bcc2eaeb97d1abcb8bebf69f3f53.camel@linux.intel.com> (raw)
Hi,
It's IMO become apparent both in the system allocator discussion and in
the patch that enables the presence of invalid vmas that we need to be
better at separating xe_vma and page-table state, so that xe_vma state
would contain things that are mostly immutable and that the user
requested: PAT index, memory attributes, requested tile presence etc,
whereas the page-table state would contain mutable state like actual
tile presence, invalidaton state and MMU notifier.
So far we have had no reason to separate the two, but with hmmptr we
would likely end up with multiple page-table regions per xe-vma, and
with the patch discussed earlier we could've easily reused
xe_vm_unbind_vma() that only touches the mutable page-table state and
does the correct locking.
The page table could would then typically take a const xe_vma *, and
and xe_pt_state *, or whatever we choose to call it. All xe_vmas except
hmmptr ones would have an 1:1 xe_vma <-> xe_pt_state relationship.
Thoughts, comments?
Thanks,
Thomas
next reply other threads:[~2024-03-12 7:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-12 7:43 Thomas Hellström [this message]
2024-03-12 23:02 ` Separating xe_vma- and page-table state Zeng, Oak
2024-03-13 1:27 ` Matthew Brost
2024-03-13 2:16 ` Zeng, Oak
2024-03-13 3:16 ` Matthew Brost
2024-03-13 10:56 ` Thomas Hellström
2024-03-13 17:06 ` Zeng, Oak
2024-03-14 8:52 ` Thomas Hellström
2024-03-14 16:00 ` Zeng, Oak
2024-03-13 19:43 ` Matthew Brost
2024-03-14 8:57 ` Thomas Hellström
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=72ea6bc36260bcc2eaeb97d1abcb8bebf69f3f53.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=oak.zeng@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