<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">That would change the semantics of
ttm_bo_mem_space() and so could change the return code in an IOCTL
as well. Not a good idea, cause that could have a lot of side
effects.<br>
<br>
Instead in the calling DC code you could check if you get an
-ENOMEM and then call schedule().<br>
<br>
If after the schedule() we see that we have now BOs on the LRU we
can try again and see if pinning the frame buffer now succeeds.<br>
<br>
Christian.<br>
<br>
Am 24.04.19 um 09:17 schrieb zhoucm1:<br>
</div>
<blockquote type="cite"
cite="mid:b57d94e6-6e20-d809-7ac2-89a39a57a365@amd.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>I made a patch as attached.</p>
<p>I'm not sure how to make patch as your proposal, Could you make
a patch for that if mine isn't enough?<br>
</p>
-David<br>
<br>
<div class="moz-cite-prefix">On 2019年04月24日 15:12, Christian König
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:32f2a1b7-99f8-de9a-799c-f98af308842b@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">
<blockquote type="cite">how about just adding a wrapper for
pin function as below?</blockquote>
I considered this as well and don't think it will work
reliable.<br>
<br>
We could use it as a band aid for this specific problem, but
in general we need to improve the handling in TTM to resolve
those kind of resource conflicts.<br>
<br>
Regards,<br>
Christian.<br>
<br>
Am 23.04.19 um 17:09 schrieb Zhou, David(ChunMing):<br>
</div>
<blockquote type="cite"
cite="mid:-jm8957cqk536djh1631fvvv-xx4wzb5q21ak-v8q7rd2l14aq-f68kxr7kbea18a7xceae626b-8s84c4d1mgrg53g0bhq3ahee89h70qrv4ly1-vf5a7d63x4mbquxnfmiehuk2-rwaw2m-qc2chu.1556032141262@email.android.com">
<meta content="text/html; charset=Windows-1252">
>3. If we have a ticket we grab a reference to the first BO
on the LRU, drop the LRU lock and try to grab the reservation
lock with the ticket.<br>
<br>
The BO on LRU is already locked by cs user, can it be dropped
here by DC user? and then DC user grab its lock with ticket,
how does CS grab it again?<br>
<br>
If you think waiting in ttm has this risk, how about just
adding a wrapper for pin function as below?<br>
amdgpu_get_pin_bo_timeout()<br>
{<br>
do {<br>
amdgpo_bo_reserve();<br>
r=amdgpu_bo_pin();<br>
<br>
if(!r)<br>
break;<br>
amdgpu_bo_unreserve();<br>
timeout--;<br>
<br>
} while(timeout>0);<br>
<br>
}<br>
<br>
-------- Original Message --------<br>
Subject: Re: [PATCH] ttm: wait mem space if user allow while
gpu busy<br>
From: Christian König <br>
To: "Zhou, David(ChunMing)" ,"Koenig, Christian" ,"Liang,
Prike" ,<a class="moz-txt-link-abbreviated"
href="mailto:dri-devel@lists.freedesktop.org"
moz-do-not-send="true">dri-devel@lists.freedesktop.org</a><br>
CC: <br>
<br>
<div>
<div class="moz-cite-prefix">Well that's not so easy of
hand.<br>
<br>
The basic problem here is that when you busy wait at this
place you can easily run into situations where application
A busy waits for B while B busy waits for A ->
deadlock.<br>
<br>
So what we need here is the deadlock detection logic of
the ww_mutex. To use this we at least need to do the
following steps:<br>
<br>
1. Reserve the BO in DC using a ww_mutex ticket (trivial).<br>
<br>
2. If we then run into this EBUSY condition in TTM check
if the BO we need memory for (or rather the ww_mutex of
its reservation object) has a ticket assigned.<br>
<br>
3. If we have a ticket we grab a reference to the first BO
on the LRU, drop the LRU lock and try to grab the
reservation lock with the ticket.<br>
<br>
4. If getting the reservation lock with the ticket
succeeded we check if the BO is still the first one on the
LRU in question (the BO could have moved).<br>
<br>
5. If the BO is still the first one on the LRU in question
we try to evict it as we would evict any other BO.<br>
<br>
6. If any of the "If's" above fail we just back off and
return -EBUSY.<br>
<br>
Steps 2-5 are certainly not trivial, but doable as far as
I can see.<br>
<br>
Have fun :)<br>
Christian.<br>
<br>
Am 23.04.19 um 15:19 schrieb Zhou, David(ChunMing):<br>
</div>
<blockquote type="cite">
<meta name="Generator" content="Microsoft Exchange Server">
<style>
<!--
.EmailQuote
{margin-left:1pt;
padding-left:4pt;
border-left:#800000 2px solid}
-->
</style>
<div>How about adding more condition ctx->resv inline
to address your concern? As well as don't wait from same
user, shouldn't lead to deadlock.<br>
<br>
Otherwise, any other idea?<br>
<br>
-------- Original Message --------<br>
Subject: Re: [PATCH] ttm: wait mem space if user allow
while gpu busy<br>
From: Christian König <br>
To: "Liang, Prike" ,"Zhou, David(ChunMing)" ,<a
class="moz-txt-link-abbreviated"
href="mailto:dri-devel@lists.freedesktop.org"
moz-do-not-send="true">dri-devel@lists.freedesktop.org</a><br>
CC: <br>
<br>
</div>
<font size="2"><span style="font-size:11pt">
<div class="PlainText">Well that is certainly a NAK
because it can lead to deadlock in the <br>
memory management.<br>
<br>
You can't just busy wait with all those locks held.<br>
<br>
Regards,<br>
Christian.<br>
<br>
Am 23.04.19 um 03:45 schrieb Liang, Prike:<br>
> Acked-by: Prike Liang <a
class="moz-txt-link-rfc2396E"
href="mailto:Prike.Liang@amd.com"
moz-do-not-send="true">
<Prike.Liang@amd.com></a><br>
><br>
> Thanks,<br>
> Prike<br>
> -----Original Message-----<br>
> From: Chunming Zhou <a
class="moz-txt-link-rfc2396E"
href="mailto:david1.zhou@amd.com"
moz-do-not-send="true">
<david1.zhou@amd.com></a><br>
> Sent: Monday, April 22, 2019 6:39 PM<br>
> To: <a class="moz-txt-link-abbreviated"
href="mailto:dri-devel@lists.freedesktop.org"
moz-do-not-send="true">
dri-devel@lists.freedesktop.org</a><br>
> Cc: Liang, Prike <a
class="moz-txt-link-rfc2396E"
href="mailto:Prike.Liang@amd.com"
moz-do-not-send="true">
<Prike.Liang@amd.com></a>; Zhou,
David(ChunMing) <a class="moz-txt-link-rfc2396E"
href="mailto:David1.Zhou@amd.com"
moz-do-not-send="true">
<David1.Zhou@amd.com></a><br>
> Subject: [PATCH] ttm: wait mem space if user
allow while gpu busy<br>
><br>
> heavy gpu job could occupy memory long time,
which could lead to other user fail to get memory.<br>
><br>
> Change-Id:
I0b322d98cd76e5ac32b00462bbae8008d76c5e11<br>
> Signed-off-by: Chunming Zhou <a
class="moz-txt-link-rfc2396E"
href="mailto:david1.zhou@amd.com"
moz-do-not-send="true">
<david1.zhou@amd.com></a><br>
> ---<br>
> drivers/gpu/drm/ttm/ttm_bo.c | 6 ++++--<br>
> 1 file changed, 4 insertions(+), 2
deletions(-)<br>
><br>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c index
7c484729f9b2..6c596cc24bec 100644<br>
> --- a/drivers/gpu/drm/ttm/ttm_bo.c<br>
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c<br>
> @@ -830,8 +830,10 @@ static int
ttm_bo_mem_force_space(struct ttm_buffer_object *bo,<br>
> if (mem->mm_node)<br>
> break;<br>
> ret = ttm_mem_evict_first(bdev,
mem_type, place, ctx);<br>
> - if (unlikely(ret != 0))<br>
> - return ret;<br>
> + if (unlikely(ret != 0)) {<br>
> + if (!ctx ||
ctx->no_wait_gpu || ret != -EBUSY)<br>
> + return ret;<br>
> + }<br>
> } while (1);<br>
> mem->mem_type = mem_type;<br>
> return ttm_bo_add_move_fence(bo, man,
mem);<br>
> --<br>
> 2.17.1<br>
><br>
> _______________________________________________<br>
> dri-devel mailing list<br>
> <a class="moz-txt-link-abbreviated"
href="mailto:dri-devel@lists.freedesktop.org"
moz-do-not-send="true">
dri-devel@lists.freedesktop.org</a><br>
> <a
href="https://lists.freedesktop.org/mailman/listinfo/dri-devel"
moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a><br>
<br>
</div>
</span></font><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre">_______________________________________________
dri-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org" moz-do-not-send="true">dri-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/dri-devel" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a></pre>
</blockquote>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dri-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org" moz-do-not-send="true">dri-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/dri-devel" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a></pre>
</blockquote>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dri-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/dri-devel">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a></pre>
</blockquote>
<br>
</body>
</html>