All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Kenny Ho <y2kenny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: amd-gfx list <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 3/3] drm/amdgpu: remove amdgpu_cs_try_evict
Date: Mon, 2 Sep 2019 16:30:58 +0200	[thread overview]
Message-ID: <4e8e46ea-4492-480e-bcd3-58cc563e4520@gmail.com> (raw)
In-Reply-To: <CAOWid-dhHxhuPRmz26POaFKnAo3LfvayGnEqA-wLCRn3kNsKsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Kenny,

When we do a CS we have a certain set of buffers which the submission is 
working with and are locked down while we prepare the submission.

This working set contains of the buffers in the BO list as well as the 
one in the VM plus one or two for CSA and user fences etc..

Now what can happen is that we find that we need to allocate some page 
tables during the CS and when a lot of BOs are locked down allocating a 
page table can fail because we can't evict other BOs.

What this code tries todo is to evict stuff from the BO list to make 
room for VM BOs, but since now much more BOs are bound to the VM this 
doesn't work any more.


The root of the problem is that it is really tricky to figure out how 
much memory you need for the page tables in the first place. See for a 
BO in VRAM we usually need only one PTE for each 2MB, but for a BO in 
system memory we need one PTE for each 4K of memory.

So what can happen is that you evict something from VRAM because you 
need room and that eviction in turn makes you need even more room.....

It can take a while until this reaches a stable point, so this patch set 
here switched from a dynamic approach to just assuming the worst and 
reserving some memory for page tables.

Regards,
Christian.

Am 02.09.19 um 16:07 schrieb Kenny Ho:
> Hey Christian,
>
> Can you go into details a bit more on the how and why this doesn't
> work well anymore?  (such as its relationship with per VM BOs?)  I am
> curious to learn more because I was reading into this chunk of code
> earlier.  Is this something that the Shrinker API can help with?
>
> Regards,
> Kenny
>
> On Mon, Sep 2, 2019 at 6:52 AM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>> Trying to evict things from the current working set doesn't work that
>> well anymore because of per VM BOs.
>>
>> Rely on reserving VRAM for page tables to avoid contention.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu.h    |  1 -
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 71 +-------------------------
>>   2 files changed, 1 insertion(+), 71 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index a236213f8e8e..d1995156733e 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -478,7 +478,6 @@ struct amdgpu_cs_parser {
>>          uint64_t                        bytes_moved_vis_threshold;
>>          uint64_t                        bytes_moved;
>>          uint64_t                        bytes_moved_vis;
>> -       struct amdgpu_bo_list_entry     *evictable;
>>
>>          /* user fence */
>>          struct amdgpu_bo_list_entry     uf_entry;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> index fd95b586b590..03182d968d3d 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> @@ -447,75 +447,12 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
>>          return r;
>>   }
>>
>> -/* Last resort, try to evict something from the current working set */
>> -static bool amdgpu_cs_try_evict(struct amdgpu_cs_parser *p,
>> -                               struct amdgpu_bo *validated)
>> -{
>> -       uint32_t domain = validated->allowed_domains;
>> -       struct ttm_operation_ctx ctx = { true, false };
>> -       int r;
>> -
>> -       if (!p->evictable)
>> -               return false;
>> -
>> -       for (;&p->evictable->tv.head != &p->validated;
>> -            p->evictable = list_prev_entry(p->evictable, tv.head)) {
>> -
>> -               struct amdgpu_bo_list_entry *candidate = p->evictable;
>> -               struct amdgpu_bo *bo = ttm_to_amdgpu_bo(candidate->tv.bo);
>> -               struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>> -               bool update_bytes_moved_vis;
>> -               uint32_t other;
>> -
>> -               /* If we reached our current BO we can forget it */
>> -               if (bo == validated)
>> -                       break;
>> -
>> -               /* We can't move pinned BOs here */
>> -               if (bo->pin_count)
>> -                       continue;
>> -
>> -               other = amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type);
>> -
>> -               /* Check if this BO is in one of the domains we need space for */
>> -               if (!(other & domain))
>> -                       continue;
>> -
>> -               /* Check if we can move this BO somewhere else */
>> -               other = bo->allowed_domains & ~domain;
>> -               if (!other)
>> -                       continue;
>> -
>> -               /* Good we can try to move this BO somewhere else */
>> -               update_bytes_moved_vis =
>> -                               !amdgpu_gmc_vram_full_visible(&adev->gmc) &&
>> -                               amdgpu_bo_in_cpu_visible_vram(bo);
>> -               amdgpu_bo_placement_from_domain(bo, other);
>> -               r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
>> -               p->bytes_moved += ctx.bytes_moved;
>> -               if (update_bytes_moved_vis)
>> -                       p->bytes_moved_vis += ctx.bytes_moved;
>> -
>> -               if (unlikely(r))
>> -                       break;
>> -
>> -               p->evictable = list_prev_entry(p->evictable, tv.head);
>> -               list_move(&candidate->tv.head, &p->validated);
>> -
>> -               return true;
>> -       }
>> -
>> -       return false;
>> -}
>> -
>>   static int amdgpu_cs_validate(void *param, struct amdgpu_bo *bo)
>>   {
>>          struct amdgpu_cs_parser *p = param;
>>          int r;
>>
>> -       do {
>> -               r = amdgpu_cs_bo_validate(p, bo);
>> -       } while (r == -ENOMEM && amdgpu_cs_try_evict(p, bo));
>> +       r = amdgpu_cs_bo_validate(p, bo);
>>          if (r)
>>                  return r;
>>
>> @@ -554,9 +491,6 @@ static int amdgpu_cs_list_validate(struct amdgpu_cs_parser *p,
>>                          binding_userptr = true;
>>                  }
>>
>> -               if (p->evictable == lobj)
>> -                       p->evictable = NULL;
>> -
>>                  r = amdgpu_cs_validate(p, bo);
>>                  if (r)
>>                          return r;
>> @@ -659,9 +593,6 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
>>                                            &p->bytes_moved_vis_threshold);
>>          p->bytes_moved = 0;
>>          p->bytes_moved_vis = 0;
>> -       p->evictable = list_last_entry(&p->validated,
>> -                                      struct amdgpu_bo_list_entry,
>> -                                      tv.head);
>>
>>          r = amdgpu_vm_validate_pt_bos(p->adev, &fpriv->vm,
>>                                        amdgpu_cs_validate, p);
>> --
>> 2.17.1
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2019-09-02 14:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-02 10:52 [PATCH 1/3] drm/amdgpu: use moving fence instead of exclusive for VM updates Christian König
     [not found] ` <20190902105219.2813-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2019-09-02 10:52   ` [PATCH 2/3] drm/amdgpu: reserve at least 4MB of VRAM for page tables Christian König
     [not found]     ` <20190902105219.2813-2-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2019-09-03  6:52       ` Zhou, David(ChunMing)
     [not found]         ` <MN2PR12MB29104DDA4EBB320F67988981B4B90-rweVpJHSKTr1t3MqfsnKMAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-09-03  8:47           ` Christian König
2019-09-02 10:52   ` [PATCH 3/3] drm/amdgpu: remove amdgpu_cs_try_evict Christian König
     [not found]     ` <20190902105219.2813-3-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2019-09-02 14:07       ` Kenny Ho
     [not found]         ` <CAOWid-dhHxhuPRmz26POaFKnAo3LfvayGnEqA-wLCRn3kNsKsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-02 14:30           ` Christian König [this message]
     [not found]             ` <4e8e46ea-4492-480e-bcd3-58cc563e4520-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-09-02 14:47               ` Kenny Ho
     [not found]                 ` <CAOWid-cCsb3OifZhuKA3-uPxj=S9TS96HBYb5b-xM-7+yzNRXA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-09-02 14:56                   ` Christian König
2019-09-03 20:37   ` [PATCH 1/3] drm/amdgpu: use moving fence instead of exclusive for VM updates Kuehling, Felix
2019-09-03  9:09 Christian König
     [not found] ` <20190903090904.30747-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2019-09-03  9:09   ` [PATCH 3/3] drm/amdgpu: remove amdgpu_cs_try_evict Christian König
     [not found]     ` <20190903090904.30747-3-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2019-09-03 12:29       ` Chunming Zhou

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=4e8e46ea-4492-480e-bcd3-58cc563e4520@gmail.com \
    --to=ckoenig.leichtzumerken-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
    --cc=y2kenny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.