AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>
To: zhoucm1 <zhoucm1-5C7GfCeVMHo@public.gmane.org>,
	"Zhou,
	David(ChunMing)" <David1.Zhou-5C7GfCeVMHo@public.gmane.org>
Cc: "dri-devel-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org"
	<dri-devel-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org>,
	amd-gfx
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH 2/3] drm/amdgpu: refresh per vm bo lru
Date: Thu, 29 Mar 2018 10:59:28 +0200	[thread overview]
Message-ID: <d7dad640-edd0-5aa3-9165-b19d44525a5b@amd.com> (raw)
In-Reply-To: <14672700-82d7-c9d8-1086-84a4d8a711bc-5C7GfCeVMHo@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 5640 bytes --]

Am 29.03.2018 um 10:37 schrieb zhoucm1:
>
>
>
> On 2018年03月28日 16:13, zhoucm1 wrote:
>>
>>
>>
>> On 2018年03月27日 21:44, Christian König wrote:
>>
>>> How about we update the LRU only when we need to re-validate at 
>>> least one BO?
>> I tried this just now, performance still isn't stable, sometime drop 
>> to 28fps by accident.

Can you give me the code for that? I probably can't work this week on 
that, but I can take a look next week.

>>
>> I also tried to check num_evictions, if eviction happens, then update 
>> LRU, also sometime drop to 28fps by accident.
>>
>> When BOs change, we not only need keep LRU order, but also validation 
>> order in vm->evicted list. Any other ideas which can keep these order 
>> but not increase submission overhead?
>
> With more thinking, we need to add new LRU design for per vm bo, we 
> need to make sure the order when adding to LRU. How about the below idea:
> 0. separate traditional bo list lru and per-vm-bo lru. Traditional lru 
> keeps old way, per-vm-lru follows below design.
> 1. TTM bdev maintains a vm/process list.
> 2. Every vm_list node contains its own per-vm-bo LRU[priority]
> 3. To manage the vm_list lru in specific driver, we will need add 
> callback for it.
> 4. We will add an order for every per-vm-bo in that vm/process.
> 5. To speed up per-vm-lru sort, we will introduce RB tree for it in 
> callback. The RB tree key is order.
>
> This way, we will be able to keep the per-vm-bo LRU order.
>
> What do you think of it?

No, we need a single LRU for per VM and not per VM BOs to maintain 
eviction fairness, so we don't really win anything with that.

Regards,
Christian.

>
> Regards,
> David Zhou
>>
>> Regards,
>> David Zhou
>>>
>>> BTW: We can easily walk all BOs which belong to a VM, skipping over 
>>> the few which aren't per VM BOs should be trivial.
>>>
>>> Christian.
>>>
>>> Am 27.03.2018 um 13:56 schrieb Zhou, David(ChunMing):
>>>> then how to keep unique lru order? any ideas?
>>>>
>>>> To stable performance, we have to keep unique lru order, otherwise 
>>>> like the issue I look into, sometimes F1game is 40fps, sometimes 
>>>> 28fps...even re-validate allowed domains BO.
>>>>
>>>> The left root cause is the moved BOs are not same.
>>>>
>>>> send from Smartisan Pro
>>>>
>>>> Christian K鰊ig <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 于 2018年3月27日 
>>>> 下午6:50写道:
>>>>
>>>> NAK, we already tried that and it is really not a good idea because it
>>>> massively increases the per submission overhead.
>>>>
>>>> Christian.
>>>>
>>>> Am 27.03.2018 um 12:16 schrieb Chunming Zhou:
>>>> > Change-Id: Ibad84ed585b0746867a5f4cd1eadc2273e7cf596
>>>> > Signed-off-by: Chunming Zhou <david1.zhou-5C7GfCeVMHo@public.gmane.org>
>>>> > ---
>>>> >   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  2 ++
>>>> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 +++++++++++++++
>>>> >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  1 +
>>>> >   3 files changed, 18 insertions(+)
>>>> >
>>>> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>>> > index 383bf2d31c92..414e61799236 100644
>>>> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>>> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>>> > @@ -919,6 +919,8 @@ static int amdgpu_bo_vm_update_pte(struct 
>>>> amdgpu_cs_parser *p)
>>>> >                }
>>>> >        }
>>>> >
>>>> > +     amdgpu_vm_refresh_lru(adev, vm);
>>>> > +
>>>> >        return r;
>>>> >   }
>>>> >
>>>> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> > index 5e35e23511cf..8ad2bb705765 100644
>>>> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> > @@ -1902,6 +1902,21 @@ struct amdgpu_bo_va 
>>>> *amdgpu_vm_bo_add(struct amdgpu_device *adev,
>>>> >        return bo_va;
>>>> >   }
>>>> >
>>>> > +void amdgpu_vm_refresh_lru(struct amdgpu_device *adev, struct 
>>>> amdgpu_vm *vm)
>>>> > +{
>>>> > +     struct ttm_bo_global *glob = adev->mman.bdev.glob;
>>>> > +     struct amdgpu_vm_bo_base *bo_base;
>>>> > +
>>>> > +     spin_lock(&vm->status_lock);
>>>> > +     list_for_each_entry(bo_base, &vm->vm_bo_list, vm_bo) {
>>>> > +             spin_lock(&glob->lru_lock);
>>>> > + ttm_bo_move_to_lru_tail(&bo_base->bo->tbo);
>>>> > +             if (bo_base->bo->shadow)
>>>> > + ttm_bo_move_to_lru_tail(&bo_base->bo->shadow->tbo);
>>>> > + spin_unlock(&glob->lru_lock);
>>>> > +     }
>>>> > +     spin_unlock(&vm->status_lock);
>>>> > +}
>>>> >
>>>> >   /**
>>>> >    * amdgpu_vm_bo_insert_mapping - insert a new mapping
>>>> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h 
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
>>>> > index 1886a561c84e..e01895581489 100644
>>>> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
>>>> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
>>>> > @@ -285,6 +285,7 @@ int amdgpu_vm_clear_freed(struct 
>>>> amdgpu_device *adev,
>>>> >                          struct dma_fence **fence);
>>>> >   int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
>>>> >                           struct amdgpu_vm *vm);
>>>> > +void amdgpu_vm_refresh_lru(struct amdgpu_device *adev, struct 
>>>> amdgpu_vm *vm);
>>>> >   int amdgpu_vm_bo_update(struct amdgpu_device *adev,
>>>> >                        struct amdgpu_bo_va *bo_va,
>>>> >                        bool clear);
>>>>
>>>
>>
>


[-- Attachment #1.2: Type: text/html, Size: 11561 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

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

  parent reply	other threads:[~2018-03-29  8:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 10:16 [PATCH 1/3] drm/amdgpu: make all per vm BOs list Chunming Zhou
     [not found] ` <20180327101654.1118-1-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2018-03-27 10:16   ` [PATCH 2/3] drm/amdgpu: refresh per vm bo lru Chunming Zhou
     [not found]     ` <20180327101654.1118-2-david1.zhou-5C7GfCeVMHo@public.gmane.org>
2018-03-27 10:50       ` Christian König
     [not found]         ` <6afa6cca-d59c-9e64-f891-c43a741069d4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-03-27 11:56           ` Zhou, David(ChunMing)
2018-03-27 13:44           ` Christian König
     [not found]             ` <a9d42a8a-b9b5-1d89-f95e-e678829a8260-5C7GfCeVMHo@public.gmane.org>
2018-03-28  8:13               ` zhoucm1
2018-03-29  8:37                 ` zhoucm1
     [not found]                   ` <14672700-82d7-c9d8-1086-84a4d8a711bc-5C7GfCeVMHo@public.gmane.org>
2018-03-29  8:59                     ` Christian König [this message]
     [not found]                       ` <d7dad640-edd0-5aa3-9165-b19d44525a5b-5C7GfCeVMHo@public.gmane.org>
2018-03-29 12:46                         ` Chunming Zhou
2018-03-27 10:16   ` [PATCH 3/3] drm/amdgpu: re-validate per VM BOs if required v2 Chunming Zhou
2018-03-27 10:52   ` [PATCH 1/3] drm/amdgpu: make all per vm BOs list Christian König

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=d7dad640-edd0-5aa3-9165-b19d44525a5b@amd.com \
    --to=christian.koenig-5c7gfcevmho@public.gmane.org \
    --cc=David1.Zhou-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=dri-devel-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org \
    --cc=zhoucm1-5C7GfCeVMHo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox