<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">No, I'm busy with P2P and recoverable
      page faults.<br>
      <br>
      Christian.<br>
      <br>
      Am 24.04.19 um 11:03 schrieb zhoucm1:<br>
    </div>
    <blockquote type="cite"
      cite="mid:f18a4a91-822b-4a0f-d038-3488fdd64c64@amd.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>OK, Let's drop mine, then Could you draft a solution for that?</p>
      <p><br>
      </p>
      <p>-David<br>
      </p>
      <br>
      <div class="moz-cite-prefix">On 2019年04月24日 16:59, Koenig,
        Christian wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:9e6e865f-29dd-be69-fada-f6a6b35e6c69@amd.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        <div class="moz-cite-prefix">Am 24.04.19 um 10:11 schrieb
          zhoucm1:<br>
        </div>
        <blockquote type="cite"
          cite="mid:cc8a8a83-a200-528f-9d31-a16115c3c00f@amd.com">
          <p><br>
          </p>
          <br>
          <div class="moz-cite-prefix">On 2019年04月24日 16:07, Christian
            König wrote:<br>
          </div>
          <blockquote type="cite"
            cite="mid:f4f27f33-5e9f-985e-ca89-5cef39bf7aaf@gmail.com">
            <div class="moz-cite-prefix">This is used in a work item, so
              you don't need to check for signals.<br>
            </div>
          </blockquote>
          will remove.<br>
          <blockquote type="cite"
            cite="mid:f4f27f33-5e9f-985e-ca89-5cef39bf7aaf@gmail.com">
            <div class="moz-cite-prefix"><br>
              And checking if the LRU is populated is mandatory here </div>
          </blockquote>
          How to check it outside of TTM? because the code is in dm.<br>
        </blockquote>
        <br>
        Well just use a static cast on the first entry of the LRU.<br>
        <br>
        We can't upstream that solution anyway, so just a hack should do
        for now.<br>
        <br>
        <blockquote type="cite"
          cite="mid:cc8a8a83-a200-528f-9d31-a16115c3c00f@amd.com"><br>
          <blockquote type="cite"
            cite="mid:f4f27f33-5e9f-985e-ca89-5cef39bf7aaf@gmail.com">
            <div class="moz-cite-prefix">or otherwise you can run into
              an endless loop.<br>
            </div>
          </blockquote>
          I already add a timeout for that.<br>
        </blockquote>
        <br>
        Thinking more about it we most likely actually need to grab the
        lock on the first BO entry from the LRU.<br>
        <br>
        <blockquote type="cite"
          cite="mid:cc8a8a83-a200-528f-9d31-a16115c3c00f@amd.com"><br>
          -David<br>
          <blockquote type="cite"
            cite="mid:f4f27f33-5e9f-985e-ca89-5cef39bf7aaf@gmail.com">
            <div class="moz-cite-prefix"><br>
              Christian.<br>
              <br>
              Am 24.04.19 um 09:59 schrieb zhoucm1:<br>
            </div>
            <blockquote type="cite"
              cite="mid:26341685-6e73-55c4-2609-52616d92c06a@amd.com">
              <p>how about new attached?</p>
              <p><br>
              </p>
              <p>-David<br>
              </p>
              <br>
              <div class="moz-cite-prefix">On 2019年04月24日 15:30,
                Christian König wrote:<br>
              </div>
              <blockquote type="cite"
                cite="mid:8db16fe8-78fe-7f25-4acd-51e37e645f3b@gmail.com">
                <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">
                  <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">
                    <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" 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" 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>
        </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>