<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Bas has the problem that CS implicitly waits for VM updates.<br>
<br>
Currently when you unmap a BO the operation will only be executed
after all the previously made CS are finished.<br>
<br>
Similar for mapping BOs. The next CS will only start after all the
pending page table updates are completed.<br>
<br>
The mapping case was already handled by my prototype patch set, but
the unmapping case still hurts a bit.<br>
<br>
This implicit sync between CS and map/unmap operations can really
hurt the performance of applications which massively use PRTs.<br>
<br>
Regards,<br>
Christian.<br>
<br>
<div class="moz-cite-prefix">Am 01.06.22 um 18:27 schrieb Marek
Olšák:<br>
</div>
<blockquote type="cite" cite="mid:CAAxE2A5Apz3u7cxCcpPuhYDj=s2Jg2vwd=2jhXbnR=3X8ZWxFw@mail.gmail.com">
<div dir="ltr">
<div>Can you please summarize what this is about?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Marek<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jun 1, 2022 at 8:40 AM
Christian König <<a href="mailto:christian.koenig@amd.com" moz-do-not-send="true" class="moz-txt-link-freetext">christian.koenig@amd.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey
guys,<br>
<br>
so today Bas came up with a new requirement regarding the
explicit <br>
synchronization to VM updates and a bunch of prototype
patches.<br>
<br>
I've been thinking about that stuff for quite some time
before, but to <br>
be honest it's one of the most trickiest parts of the driver.<br>
<br>
So my current thinking is that we could potentially handle
those <br>
requirements like this:<br>
<br>
1. We add some new EXPLICIT flag to context (or CS?) and VM
IOCTL. This <br>
way we either get the new behavior for the whole CS+VM or the
old one, <br>
but never both mixed.<br>
<br>
2. When memory is unmapped we keep around the last unmap
operation <br>
inside the bo_va.<br>
<br>
3. When memory is freed we add all the CS fences which could
access that <br>
memory + the last unmap operation as BOOKKEEP fences to the BO
and as <br>
mandatory sync fence to the VM.<br>
<br>
Memory freed either because of an eviction or because of
userspace <br>
closing the handle will be seen as a combination of
unmap+free.<br>
<br>
<br>
The result is the following semantic for userspace to avoid
implicit <br>
synchronization as much as possible:<br>
<br>
1. When you allocate and map memory it is mandatory to either
wait for <br>
the mapping operation to complete or to add it as dependency
for your CS.<br>
If this isn't followed the application will run into CS
faults <br>
(that's what we pretty much already implemented).<br>
<br>
2. When memory is freed you must unmap that memory first and
then wait <br>
for this unmap operation to complete before freeing the
memory.<br>
If this isn't followed the kernel will add a forcefully
wait to the <br>
next CS to block until the unmap is completed.<br>
<br>
3. All VM operations requested by userspace will still be
executed in <br>
order, e.g. we can't run unmap + map in parallel or something
like this.<br>
<br>
Is that something you guys can live with? As far as I can see
it should <br>
give you the maximum freedom possible, but is still doable.<br>
<br>
Regards,<br>
Christian.<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>