Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
I pushed my patch series that simplifies eviction fence handling in KFD.
If you rebase this, it should be OK now.
Regards,
Felix
On 2019-02-04 7:42 a.m., Christian König wrote:
> Let's start to allocate VM PDs/PTs on demand instead of pre-allocating
> them during mapping.
>
> Signed-off-by: Christian König
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 -
> 5 files changed, 38 insertions(+), 126 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index d7b10d79f1de..2176c92f9377 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -492,12 +492,6 @@ static int add_bo_to_vm(struct amdgpu_device *adev,
> struct kgd_mem *mem,
> vm->process_info->eviction_fence,
> NULL, NULL);
>
> - ret = amdgpu_vm_alloc_pts(adev, vm, va, amdgpu_bo_size(bo));
> - if (ret) {
> - pr_err("Failed to allocate pts, err=%d\n", ret);
> - goto err_alloc_pts;
> - }
> -
> ret = vm_validate_pt_pd_bos(vm);
> if (ret) {
> pr_err("validate_pt_pd_bos() failed\n");
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> index 7e22be7ca68a..54dd02a898b9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> @@ -92,15 +92,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev,
> struct amdgpu_vm *vm,
> return -ENOMEM;
> }
>
> - r = amdgpu_vm_alloc_pts(adev, (*bo_va)->base.vm, csa_addr,
> - size);
> - if (r) {
> - DRM_ERROR("failed to allocate pts for static CSA, err=%d\n", r);
> - amdgpu_vm_bo_rmv(adev, *bo_va);
> - ttm_eu_backoff_reservation(, );
> - return r;
> - }
> -
> r = amdgpu_vm_bo_map(adev, *bo_va, csa_addr, 0, size,
>AMDGPU_PTE_READABLE | AMDGPU_PTE_WRITEABLE |
>AMDGPU_PTE_EXECUTABLE);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index d21dd2f369da..e141e3b13112 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -627,11 +627,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void
> *data,
>
> switch (args->operation) {
> case AMDGPU_VA_OP_MAP:
> - r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
> - args->map_size);
> - if (r)
> - goto error_backoff;
> -
> va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
> r = amdgpu_vm_bo_map(adev, bo_va, args->va_address,
>args->offset_in_bo, args->map_size,
> @@ -647,11 +642,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void
> *data,
> args->map_size);
> break;
> case AMDGPU_VA_OP_REPLACE:
> - r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
> - args->map_size);
> - if (r)
> - goto error_backoff;
> -
> va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
> r = amdgpu_vm_bo_replace_map(adev, bo_va, args->va_address,
>args->offset_in_bo, args->map_size,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index f7d410a5d848..0b8a1aa56c4a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -504,47 +504,6 @@ static void amdgpu_vm_pt_next(struct amdgpu_device *adev,
> }
> }
>
> -/**
> - * amdgpu_vm_pt_first_leaf - get first leaf PD/PT
> - *
> - * @adev: amdgpu_device pointer
> - * @vm: amdgpu_vm structure
> - * @start: start addr of the walk
> - * @cursor: state to initialize
> - *
> - * Start a walk and go directly to the leaf node.
> - */
> -static void amdgpu_vm_pt_first_leaf(struct amdgpu_device *adev,
> - struct amdgpu_vm *vm, uint64_t start,
> - struct amdgpu_vm_pt_cursor *cursor)
> -{
> - amdgpu_vm_pt_start(adev, vm, start, cursor);
> - while (amdgpu_vm_pt_descendant(adev, cursor));
> -}
> -
> -/**
> - * amdgpu_vm_pt_next_leaf - get next leaf PD/PT
> - *
> - * @adev: amdgpu_device pointer
> - * @cursor: current state
> - *
> - * Walk the PD/PT tree to the
Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
I mostly figured out what was going on. See my comments inline below. I'll send out a patch series in a minute that cleans up and simplifies the eviction fence handling so we no longer need to remove eviction fences temporarily. On 2019-02-06 4:06 a.m., Koenig, Christian wrote: > Am 06.02.19 um 00:51 schrieb Kuehling, Felix: >> On 2019-02-05 11:00 a.m., Koenig, Christian wrote: >>> Ah! The initial clear of the PDs is syncing to everything! >> Right. Using amdgpu_sync_resv(... AMDGPU_FENCE_OWNER_VM ...) in >> amdgpu_vm_clear_bo seems to help. But if I also change the >> amdgpu_job_submit to use AMDGPU_FENCE_OWNER_VM, I get a VM fault and CP >> hang very early in my test. Not sure what's happening there. This is >> what I changed: >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c >> index 8b240f9..06c28ac 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c >> @@ -826,17 +826,18 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device >> *adev, >> >>WARN_ON(job->ibs[0].length_dw > 64); >>r = amdgpu_sync_resv(adev, >sync, bo->tbo.resv, >> -AMDGPU_FENCE_OWNER_UNDEFINED, false); >> +AMDGPU_FENCE_OWNER_VM, false); > That's correct. I changed this to FENCE_OWNER_KFD in my patch series. So it will still synchronize with everything, except eviction fences. The same treatment was needed for the synchronization when clearing page table entries in amdgpu_vm_bo_update_mapping. > >>if (r) >>goto error_free; >> >> - r = amdgpu_job_submit(job, >entity, AMDGPU_FENCE_OWNER_UNDEFINED, >> + r = amdgpu_job_submit(job, >entity, AMDGPU_FENCE_OWNER_VM, > This change most likely doesn't make a difference. It ended up affecting synchronization with subsequent CPU page table updates. See below. > >> ); >>if (r) >>goto error_free; >> >>amdgpu_bo_fence(bo, fence, true); >> - dma_fence_put(fence); >> + dma_fence_put(vm->last_update); >> + vm->last_update = fence; > This is most likely incorrect. This wasn't needed. I was hoping it would fix the problem, but didn't. > >> >>if (bo->shadow) >>return amdgpu_vm_clear_bo(adev, vm, bo->shadow, >> >> Basically I tried to do the synchronization exactly like >> amdgpu_vm_update_directories. >> >> The only way this clear could cause a VM fault is, if a subsequent >> PTE/PDS update happens too early and gets overwritten by the pending >> clear. But don't the clear and the next PTE/PDE update go to the same >> queue (vm->entity) and are implicitly synchronized? > Need to check where this is coming from. > >> Answer after another hour of pouring over code and history: No, sched >> entities are no longer equivalent to queues. The scheduler can itself >> load-balance VM updates using multiple SDMA queues. Sigh. > That is unproblematic. Load balancing happens only when the entity is idle. > > E.g. submissions to the same entity never run in parallel. It was because of CPU page table updates that failed to synchronize with the vm_clear_bo when I changed the fence owner for this submission. Damn resizable BAR. ;) I wasn't expecting this on my small-BAR Fiji and ended up chasing my tail for a while. Regards, Felix > >> OK, so page table updates to different PTEs don't usually need to >> synchronize with each other. But how do page table updates to the same >> address get synchronized? How do you guarantee that two updates of the >> same PTE are processed by the hardware in the correct order, if >> AMDGPU_FENCE_OWNER_VM fences don't synchronize with each other? > Mhm, need to double check but that explanation doesn't seem to fit. > There must be something else going on. > >> >>> Ok, that is easy to fix. >> Not that easy. See above. ;) > Well need to take a closer look why you run into VM faults, but > basically replacing the parameter in amdgpu_sync_resv should already do > the trick. > > Regards, > Christian. > >> Regards, >> Felix >> >> >> >>> Christian. >>> >>> Am 05.02.19 um 16:49 schrieb Kuehling, Felix: >>>> I saw a backtrace from the GPU scheduler when I was debugging this >>>> yesterday, but those backtraces never tell us where the command submission >>>> came from. It could
Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
Am 06.02.19 um 00:51 schrieb Kuehling, Felix: > On 2019-02-05 11:00 a.m., Koenig, Christian wrote: >> Ah! The initial clear of the PDs is syncing to everything! > Right. Using amdgpu_sync_resv(... AMDGPU_FENCE_OWNER_VM ...) in > amdgpu_vm_clear_bo seems to help. But if I also change the > amdgpu_job_submit to use AMDGPU_FENCE_OWNER_VM, I get a VM fault and CP > hang very early in my test. Not sure what's happening there. This is > what I changed: > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > index 8b240f9..06c28ac 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > @@ -826,17 +826,18 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device > *adev, > > WARN_ON(job->ibs[0].length_dw > 64); > r = amdgpu_sync_resv(adev, >sync, bo->tbo.resv, > -AMDGPU_FENCE_OWNER_UNDEFINED, false); > +AMDGPU_FENCE_OWNER_VM, false); That's correct. > if (r) > goto error_free; > > - r = amdgpu_job_submit(job, >entity, AMDGPU_FENCE_OWNER_UNDEFINED, > + r = amdgpu_job_submit(job, >entity, AMDGPU_FENCE_OWNER_VM, This change most likely doesn't make a difference. > ); > if (r) > goto error_free; > > amdgpu_bo_fence(bo, fence, true); > - dma_fence_put(fence); > + dma_fence_put(vm->last_update); > + vm->last_update = fence; This is most likely incorrect. > > if (bo->shadow) > return amdgpu_vm_clear_bo(adev, vm, bo->shadow, > > Basically I tried to do the synchronization exactly like > amdgpu_vm_update_directories. > > The only way this clear could cause a VM fault is, if a subsequent > PTE/PDS update happens too early and gets overwritten by the pending > clear. But don't the clear and the next PTE/PDE update go to the same > queue (vm->entity) and are implicitly synchronized? Need to check where this is coming from. > Answer after another hour of pouring over code and history: No, sched > entities are no longer equivalent to queues. The scheduler can itself > load-balance VM updates using multiple SDMA queues. Sigh. That is unproblematic. Load balancing happens only when the entity is idle. E.g. submissions to the same entity never run in parallel. > OK, so page table updates to different PTEs don't usually need to > synchronize with each other. But how do page table updates to the same > address get synchronized? How do you guarantee that two updates of the > same PTE are processed by the hardware in the correct order, if > AMDGPU_FENCE_OWNER_VM fences don't synchronize with each other? Mhm, need to double check but that explanation doesn't seem to fit. There must be something else going on. > > >> Ok, that is easy to fix. > Not that easy. See above. ;) Well need to take a closer look why you run into VM faults, but basically replacing the parameter in amdgpu_sync_resv should already do the trick. Regards, Christian. > > Regards, > Felix > > > >> Christian. >> >> Am 05.02.19 um 16:49 schrieb Kuehling, Felix: >>> I saw a backtrace from the GPU scheduler when I was debugging this >>> yesterday, but those backtraces never tell us where the command submission >>> came from. It could be memory initialization, or some migration at >>> buffer-validation. Basically, any command submission triggered by page >>> table allocation that synchronizes with the PD reservation object is a >>> problem. >>> >>> Regards, >>> Felix >>> >>> -Original Message- >>> From: Christian König >>> Sent: Tuesday, February 05, 2019 10:40 AM >>> To: Kuehling, Felix ; Koenig, Christian >>> ; amd-gfx@lists.freedesktop.org >>> Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand >>> >>> Am 05.02.19 um 16:20 schrieb Kuehling, Felix: >>>>>> This may cause regressions in KFD if PT BO allocation can trigger >>>>>> eviction fences. >>>>> I don't think that can happen, but need to double check as well. >>>>> >>>>> Otherwise allocating page tables could try to evict other page tables >>>>> from the same process and that seriously doesn't make much sense. >>>> Eviction fences don't cause actual memory evictions. They are the result >>>> of memory evictions. They cause KFD processes to be preempted in order to >>>> allow the fence to si
Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
On 2019-02-05 11:00 a.m., Koenig, Christian wrote: > Ah! The initial clear of the PDs is syncing to everything! Right. Using amdgpu_sync_resv(... AMDGPU_FENCE_OWNER_VM ...) in amdgpu_vm_clear_bo seems to help. But if I also change the amdgpu_job_submit to use AMDGPU_FENCE_OWNER_VM, I get a VM fault and CP hang very early in my test. Not sure what's happening there. This is what I changed: diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 8b240f9..06c28ac 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -826,17 +826,18 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev, WARN_ON(job->ibs[0].length_dw > 64); r = amdgpu_sync_resv(adev, >sync, bo->tbo.resv, -AMDGPU_FENCE_OWNER_UNDEFINED, false); +AMDGPU_FENCE_OWNER_VM, false); if (r) goto error_free; - r = amdgpu_job_submit(job, >entity, AMDGPU_FENCE_OWNER_UNDEFINED, + r = amdgpu_job_submit(job, >entity, AMDGPU_FENCE_OWNER_VM, ); if (r) goto error_free; amdgpu_bo_fence(bo, fence, true); - dma_fence_put(fence); + dma_fence_put(vm->last_update); + vm->last_update = fence; if (bo->shadow) return amdgpu_vm_clear_bo(adev, vm, bo->shadow, Basically I tried to do the synchronization exactly like amdgpu_vm_update_directories. The only way this clear could cause a VM fault is, if a subsequent PTE/PDS update happens too early and gets overwritten by the pending clear. But don't the clear and the next PTE/PDE update go to the same queue (vm->entity) and are implicitly synchronized? Answer after another hour of pouring over code and history: No, sched entities are no longer equivalent to queues. The scheduler can itself load-balance VM updates using multiple SDMA queues. Sigh. OK, so page table updates to different PTEs don't usually need to synchronize with each other. But how do page table updates to the same address get synchronized? How do you guarantee that two updates of the same PTE are processed by the hardware in the correct order, if AMDGPU_FENCE_OWNER_VM fences don't synchronize with each other? > > Ok, that is easy to fix. Not that easy. See above. ;) Regards, Felix > > Christian. > > Am 05.02.19 um 16:49 schrieb Kuehling, Felix: >> I saw a backtrace from the GPU scheduler when I was debugging this >> yesterday, but those backtraces never tell us where the command submission >> came from. It could be memory initialization, or some migration at >> buffer-validation. Basically, any command submission triggered by page table >> allocation that synchronizes with the PD reservation object is a problem. >> >> Regards, >> Felix >> >> -Original Message- >> From: Christian König >> Sent: Tuesday, February 05, 2019 10:40 AM >> To: Kuehling, Felix ; Koenig, Christian >> ; amd-gfx@lists.freedesktop.org >> Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand >> >> Am 05.02.19 um 16:20 schrieb Kuehling, Felix: >>>>> This may cause regressions in KFD if PT BO allocation can trigger >>>>> eviction fences. >>>> I don't think that can happen, but need to double check as well. >>>> >>>> Otherwise allocating page tables could try to evict other page tables from >>>> the same process and that seriously doesn't make much sense. >>> Eviction fences don't cause actual memory evictions. They are the result of >>> memory evictions. They cause KFD processes to be preempted in order to >>> allow the fence to signal so memory can be evicted. The problem is that a >>> page table allocation waits for the fences on the PD reservation, which >>> looks like an eviction to KFD and triggers an unnecessary preemption. There >>> is no actual memory eviction happening here. >> Yeah, but where is that actually coming from? >> >> It sounds like we still unnecessary synchronize page table updates somewhere. >> >> Do you have a call chain? >> >> Regards, >> Christian. >> >>> Regards, >>> Felix >>> >>> -Original Message- >>> From: Christian König >>> Sent: Tuesday, February 05, 2019 6:37 AM >>> To: Kuehling, Felix ; >>> amd-gfx@lists.freedesktop.org >>> Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand >>> >>>> This may cause regressions in KFD if PT BO allocation can trigger >>>> eviction fences. >>
Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
Ah! The initial clear of the PDs is syncing to everything! Ok, that is easy to fix. Christian. Am 05.02.19 um 16:49 schrieb Kuehling, Felix: > I saw a backtrace from the GPU scheduler when I was debugging this yesterday, > but those backtraces never tell us where the command submission came from. It > could be memory initialization, or some migration at buffer-validation. > Basically, any command submission triggered by page table allocation that > synchronizes with the PD reservation object is a problem. > > Regards, >Felix > > -Original Message- > From: Christian König > Sent: Tuesday, February 05, 2019 10:40 AM > To: Kuehling, Felix ; Koenig, Christian > ; amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand > > Am 05.02.19 um 16:20 schrieb Kuehling, Felix: >>>> This may cause regressions in KFD if PT BO allocation can trigger >>>> eviction fences. >>> I don't think that can happen, but need to double check as well. >>> >>> Otherwise allocating page tables could try to evict other page tables from >>> the same process and that seriously doesn't make much sense. >> Eviction fences don't cause actual memory evictions. They are the result of >> memory evictions. They cause KFD processes to be preempted in order to allow >> the fence to signal so memory can be evicted. The problem is that a page >> table allocation waits for the fences on the PD reservation, which looks >> like an eviction to KFD and triggers an unnecessary preemption. There is no >> actual memory eviction happening here. > Yeah, but where is that actually coming from? > > It sounds like we still unnecessary synchronize page table updates somewhere. > > Do you have a call chain? > > Regards, > Christian. > >> Regards, >> Felix >> >> -Original Message- >> From: Christian König >> Sent: Tuesday, February 05, 2019 6:37 AM >> To: Kuehling, Felix ; >> amd-gfx@lists.freedesktop.org >> Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand >> >>> This may cause regressions in KFD if PT BO allocation can trigger >>> eviction fences. >> I don't think that can happen, but need to double check as well. >> >> Otherwise allocating page tables could try to evict other page tables from >> the same process and that seriously doesn't make much sense. >> >>> Do you know whether PT BO allocation would wait on the page-directory >>> reservation object without the sync-object API anywhere? >> For inside the kernel I can't think of any relevant use case, except for the >> eviction call path and there it is intentional. >> >> One thing which will always wait for all fences is the display code path, >> but that is not relevant here. (Isn't it?). >> >> What might be questionable is amdgpu_gem_wait_idle_ioctl(), but I think this >> is also completely intentional that we wait on everything here. >> >> Regards, >> Christian. >> >> Am 04.02.19 um 21:17 schrieb Kuehling, Felix: >>> This may cause regressions in KFD if PT BO allocation can trigger >>> eviction fences. The previous call to amdgpu_vm_alloc_pts was in a >>> context where we had temporarily removed the eviction fence. PT BO >>> allocation in amdgpu_vm_bo_update is not protected like that. >>> >>> I vaguely remember looking into this last time you were working on >>> our eviction fence code and thinking that most of the cases where we >>> remove the eviction fence were no longer needed if fence >>> synchronization happens through the amdgpu_sync-object API (rather >>> than waiting on a reservation object directly). I think it's time I >>> go and finally clean that up. >>> >>> Do you know whether PT BO allocation would wait on the page-directory >>> reservation object without the sync-object API anywhere? >>> >>> Regards, >>> Felix >>> >>> On 2019-02-04 7:42 a.m., Christian König wrote: >>>> Let's start to allocate VM PDs/PTs on demand instead of >>>> pre-allocating them during mapping. >>>> >>>> Signed-off-by: Christian König >>>> --- >>>> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 - >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 -- >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 -- >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +- >>>> drivers/gpu/drm/
RE: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
I saw a backtrace from the GPU scheduler when I was debugging this yesterday, but those backtraces never tell us where the command submission came from. It could be memory initialization, or some migration at buffer-validation. Basically, any command submission triggered by page table allocation that synchronizes with the PD reservation object is a problem. Regards, Felix -Original Message- From: Christian König Sent: Tuesday, February 05, 2019 10:40 AM To: Kuehling, Felix ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand Am 05.02.19 um 16:20 schrieb Kuehling, Felix: >>> This may cause regressions in KFD if PT BO allocation can trigger >>> eviction fences. >> I don't think that can happen, but need to double check as well. >> >> Otherwise allocating page tables could try to evict other page tables from >> the same process and that seriously doesn't make much sense. > Eviction fences don't cause actual memory evictions. They are the result of > memory evictions. They cause KFD processes to be preempted in order to allow > the fence to signal so memory can be evicted. The problem is that a page > table allocation waits for the fences on the PD reservation, which looks like > an eviction to KFD and triggers an unnecessary preemption. There is no actual > memory eviction happening here. Yeah, but where is that actually coming from? It sounds like we still unnecessary synchronize page table updates somewhere. Do you have a call chain? Regards, Christian. > > Regards, >Felix > > -Original Message- > From: Christian König > Sent: Tuesday, February 05, 2019 6:37 AM > To: Kuehling, Felix ; > amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand > >> This may cause regressions in KFD if PT BO allocation can trigger >> eviction fences. > I don't think that can happen, but need to double check as well. > > Otherwise allocating page tables could try to evict other page tables from > the same process and that seriously doesn't make much sense. > >> Do you know whether PT BO allocation would wait on the page-directory >> reservation object without the sync-object API anywhere? > For inside the kernel I can't think of any relevant use case, except for the > eviction call path and there it is intentional. > > One thing which will always wait for all fences is the display code path, but > that is not relevant here. (Isn't it?). > > What might be questionable is amdgpu_gem_wait_idle_ioctl(), but I think this > is also completely intentional that we wait on everything here. > > Regards, > Christian. > > Am 04.02.19 um 21:17 schrieb Kuehling, Felix: >> This may cause regressions in KFD if PT BO allocation can trigger >> eviction fences. The previous call to amdgpu_vm_alloc_pts was in a >> context where we had temporarily removed the eviction fence. PT BO >> allocation in amdgpu_vm_bo_update is not protected like that. >> >> I vaguely remember looking into this last time you were working on >> our eviction fence code and thinking that most of the cases where we >> remove the eviction fence were no longer needed if fence >> synchronization happens through the amdgpu_sync-object API (rather >> than waiting on a reservation object directly). I think it's time I >> go and finally clean that up. >> >> Do you know whether PT BO allocation would wait on the page-directory >> reservation object without the sync-object API anywhere? >> >> Regards, >> Felix >> >> On 2019-02-04 7:42 a.m., Christian König wrote: >>> Let's start to allocate VM PDs/PTs on demand instead of >>> pre-allocating them during mapping. >>> >>> Signed-off-by: Christian König >>> --- >>> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 - >>> drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 -- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 -- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 - >>> 5 files changed, 38 insertions(+), 126 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c >>> index d7b10d79f1de..2176c92f9377 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c >>> @@ -492,12 +492,6 @@ static int add_bo_to_vm(struct amdgpu_device *adev, >>>
Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
Am 05.02.19 um 16:20 schrieb Kuehling, Felix:
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences.
I don't think that can happen, but need to double check as well.
Otherwise allocating page tables could try to evict other page tables from the
same process and that seriously doesn't make much sense.
Eviction fences don't cause actual memory evictions. They are the result of
memory evictions. They cause KFD processes to be preempted in order to allow
the fence to signal so memory can be evicted. The problem is that a page table
allocation waits for the fences on the PD reservation, which looks like an
eviction to KFD and triggers an unnecessary preemption. There is no actual
memory eviction happening here.
Yeah, but where is that actually coming from?
It sounds like we still unnecessary synchronize page table updates
somewhere.
Do you have a call chain?
Regards,
Christian.
Regards,
Felix
-Original Message-
From: Christian König
Sent: Tuesday, February 05, 2019 6:37 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences.
I don't think that can happen, but need to double check as well.
Otherwise allocating page tables could try to evict other page tables from the
same process and that seriously doesn't make much sense.
Do you know whether PT BO allocation would wait on the page-directory
reservation object without the sync-object API anywhere?
For inside the kernel I can't think of any relevant use case, except for the
eviction call path and there it is intentional.
One thing which will always wait for all fences is the display code path, but
that is not relevant here. (Isn't it?).
What might be questionable is amdgpu_gem_wait_idle_ioctl(), but I think this is
also completely intentional that we wait on everything here.
Regards,
Christian.
Am 04.02.19 um 21:17 schrieb Kuehling, Felix:
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
context where we had temporarily removed the eviction fence. PT BO
allocation in amdgpu_vm_bo_update is not protected like that.
I vaguely remember looking into this last time you were working on our
eviction fence code and thinking that most of the cases where we
remove the eviction fence were no longer needed if fence
synchronization happens through the amdgpu_sync-object API (rather
than waiting on a reservation object directly). I think it's time I go
and finally clean that up.
Do you know whether PT BO allocation would wait on the page-directory
reservation object without the sync-object API anywhere?
Regards,
Felix
On 2019-02-04 7:42 a.m., Christian König wrote:
Let's start to allocate VM PDs/PTs on demand instead of
pre-allocating them during mapping.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 -
5 files changed, 38 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index d7b10d79f1de..2176c92f9377 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -492,12 +492,6 @@ static int add_bo_to_vm(struct amdgpu_device *adev, struct
kgd_mem *mem,
vm->process_info->eviction_fence,
NULL, NULL);
- ret = amdgpu_vm_alloc_pts(adev, vm, va, amdgpu_bo_size(bo));
- if (ret) {
- pr_err("Failed to allocate pts, err=%d\n", ret);
- goto err_alloc_pts;
- }
-
ret = vm_validate_pt_pd_bos(vm);
if (ret) {
pr_err("validate_pt_pd_bos() failed\n"); diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 7e22be7ca68a..54dd02a898b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -92,15 +92,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
return -ENOMEM;
}
- r = amdgpu_vm_alloc_pts(adev, (*bo_va)->base.vm, csa_addr,
- size);
- if (r) {
- DRM_ERROR("failed to allocate pts for static CSA, err=%d\n", r);
- amdgpu_vm_bo_rmv(adev, *bo_va);
- ttm_eu_backoff_reservation(, );
- return r;
- }
-
r = amdgpu_vm_bo_map(adev, *bo_va, csa_addr, 0, size,
AMD
RE: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
> > This may cause regressions in KFD if PT BO allocation can trigger
> > eviction fences.
> I don't think that can happen, but need to double check as well.
>
> Otherwise allocating page tables could try to evict other page tables from
> the same process and that seriously doesn't make much sense.
Eviction fences don't cause actual memory evictions. They are the result of
memory evictions. They cause KFD processes to be preempted in order to allow
the fence to signal so memory can be evicted. The problem is that a page table
allocation waits for the fences on the PD reservation, which looks like an
eviction to KFD and triggers an unnecessary preemption. There is no actual
memory eviction happening here.
Regards,
Felix
-Original Message-
From: Christian König
Sent: Tuesday, February 05, 2019 6:37 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
> This may cause regressions in KFD if PT BO allocation can trigger
> eviction fences.
I don't think that can happen, but need to double check as well.
Otherwise allocating page tables could try to evict other page tables from the
same process and that seriously doesn't make much sense.
> Do you know whether PT BO allocation would wait on the page-directory
> reservation object without the sync-object API anywhere?
For inside the kernel I can't think of any relevant use case, except for the
eviction call path and there it is intentional.
One thing which will always wait for all fences is the display code path, but
that is not relevant here. (Isn't it?).
What might be questionable is amdgpu_gem_wait_idle_ioctl(), but I think this is
also completely intentional that we wait on everything here.
Regards,
Christian.
Am 04.02.19 um 21:17 schrieb Kuehling, Felix:
> This may cause regressions in KFD if PT BO allocation can trigger
> eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
> context where we had temporarily removed the eviction fence. PT BO
> allocation in amdgpu_vm_bo_update is not protected like that.
>
> I vaguely remember looking into this last time you were working on our
> eviction fence code and thinking that most of the cases where we
> remove the eviction fence were no longer needed if fence
> synchronization happens through the amdgpu_sync-object API (rather
> than waiting on a reservation object directly). I think it's time I go
> and finally clean that up.
>
> Do you know whether PT BO allocation would wait on the page-directory
> reservation object without the sync-object API anywhere?
>
> Regards,
> Felix
>
> On 2019-02-04 7:42 a.m., Christian König wrote:
>> Let's start to allocate VM PDs/PTs on demand instead of
>> pre-allocating them during mapping.
>>
>> Signed-off-by: Christian König
>> ---
>>.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -
>>drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 --
>>drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 --
>>drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +-
>>drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 -
>>5 files changed, 38 insertions(+), 126 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index d7b10d79f1de..2176c92f9377 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -492,12 +492,6 @@ static int add_bo_to_vm(struct amdgpu_device *adev,
>> struct kgd_mem *mem,
>> vm->process_info->eviction_fence,
>> NULL, NULL);
>>
>> -ret = amdgpu_vm_alloc_pts(adev, vm, va, amdgpu_bo_size(bo));
>> -if (ret) {
>> -pr_err("Failed to allocate pts, err=%d\n", ret);
>> -goto err_alloc_pts;
>> -}
>> -
>> ret = vm_validate_pt_pd_bos(vm);
>> if (ret) {
>> pr_err("validate_pt_pd_bos() failed\n"); diff --git
>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>> index 7e22be7ca68a..54dd02a898b9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>> @@ -92,15 +92,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev,
>> struct amdgpu_vm *vm,
>> return -ENOMEM;
>> }
>>
>> -r = amdgpu_vm_alloc_pts(adev, (*bo_va)->base.vm, csa_addr,
>> -size);
>> -if (r) {
>> -DRM_ERROR(&q
Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
Am 05.02.19 um 01:33 schrieb Kuehling, Felix:
On 2019-02-04 3:17 p.m., Kuehling, Felix wrote:
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
context where we had temporarily removed the eviction fence. PT BO
allocation in amdgpu_vm_bo_update is not protected like that.
I vaguely remember looking into this last time you were working on our
eviction fence code and thinking that most of the cases where we remove
the eviction fence were no longer needed if fence synchronization
happens through the amdgpu_sync-object API (rather than waiting on a
reservation object directly). I think it's time I go and finally clean
that up.
I'm looking at this now. It's not working as I was hoping.
Do you know whether PT BO allocation would wait on the page-directory
reservation object without the sync-object API anywhere?
It doesn't even matter. Buffer moves (anything calling amdgpu_sync_resv
with AMDGPU_FENCE_OWNER_UNDEFINED) are supposed to trigger eviction
fences. So page table BO allocation triggers eviction fences on the PD
reservation. I don't know how to avoid this other than by removing the
eviction fence while allocating PT BOs. With your changes this will be
potentially every time we map or unmap memory.
Any better ideas?
Let me take a closer look what exactly is happening here.
Regards,
Christian.
Regards,
Felix
Regards,
Felix
On 2019-02-04 7:42 a.m., Christian König wrote:
Let's start to allocate VM PDs/PTs on demand instead of pre-allocating
them during mapping.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 -
5 files changed, 38 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index d7b10d79f1de..2176c92f9377 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -492,12 +492,6 @@ static int add_bo_to_vm(struct amdgpu_device *adev, struct
kgd_mem *mem,
vm->process_info->eviction_fence,
NULL, NULL);
- ret = amdgpu_vm_alloc_pts(adev, vm, va, amdgpu_bo_size(bo));
- if (ret) {
- pr_err("Failed to allocate pts, err=%d\n", ret);
- goto err_alloc_pts;
- }
-
ret = vm_validate_pt_pd_bos(vm);
if (ret) {
pr_err("validate_pt_pd_bos() failed\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 7e22be7ca68a..54dd02a898b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -92,15 +92,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
return -ENOMEM;
}
- r = amdgpu_vm_alloc_pts(adev, (*bo_va)->base.vm, csa_addr,
- size);
- if (r) {
- DRM_ERROR("failed to allocate pts for static CSA, err=%d\n", r);
- amdgpu_vm_bo_rmv(adev, *bo_va);
- ttm_eu_backoff_reservation(, );
- return r;
- }
-
r = amdgpu_vm_bo_map(adev, *bo_va, csa_addr, 0, size,
AMDGPU_PTE_READABLE | AMDGPU_PTE_WRITEABLE |
AMDGPU_PTE_EXECUTABLE);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index d21dd2f369da..e141e3b13112 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -627,11 +627,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
switch (args->operation) {
case AMDGPU_VA_OP_MAP:
- r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
- args->map_size);
- if (r)
- goto error_backoff;
-
va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
r = amdgpu_vm_bo_map(adev, bo_va, args->va_address,
args->offset_in_bo, args->map_size,
@@ -647,11 +642,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
args->map_size);
break;
case AMDGPU_VA_OP_REPLACE:
- r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
- args->map_size);
- if (r)
- goto error_backoff;
-
va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
r =
Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences.
I don't think that can happen, but need to double check as well.
Otherwise allocating page tables could try to evict other page tables
from the same process and that seriously doesn't make much sense.
Do you know whether PT BO allocation would wait on the page-directory
reservation object without the sync-object API anywhere?
For inside the kernel I can't think of any relevant use case, except for
the eviction call path and there it is intentional.
One thing which will always wait for all fences is the display code
path, but that is not relevant here. (Isn't it?).
What might be questionable is amdgpu_gem_wait_idle_ioctl(), but I think
this is also completely intentional that we wait on everything here.
Regards,
Christian.
Am 04.02.19 um 21:17 schrieb Kuehling, Felix:
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
context where we had temporarily removed the eviction fence. PT BO
allocation in amdgpu_vm_bo_update is not protected like that.
I vaguely remember looking into this last time you were working on our
eviction fence code and thinking that most of the cases where we remove
the eviction fence were no longer needed if fence synchronization
happens through the amdgpu_sync-object API (rather than waiting on a
reservation object directly). I think it's time I go and finally clean
that up.
Do you know whether PT BO allocation would wait on the page-directory
reservation object without the sync-object API anywhere?
Regards,
Felix
On 2019-02-04 7:42 a.m., Christian König wrote:
Let's start to allocate VM PDs/PTs on demand instead of pre-allocating
them during mapping.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 -
5 files changed, 38 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index d7b10d79f1de..2176c92f9377 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -492,12 +492,6 @@ static int add_bo_to_vm(struct amdgpu_device *adev, struct
kgd_mem *mem,
vm->process_info->eviction_fence,
NULL, NULL);
- ret = amdgpu_vm_alloc_pts(adev, vm, va, amdgpu_bo_size(bo));
- if (ret) {
- pr_err("Failed to allocate pts, err=%d\n", ret);
- goto err_alloc_pts;
- }
-
ret = vm_validate_pt_pd_bos(vm);
if (ret) {
pr_err("validate_pt_pd_bos() failed\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 7e22be7ca68a..54dd02a898b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -92,15 +92,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
return -ENOMEM;
}
- r = amdgpu_vm_alloc_pts(adev, (*bo_va)->base.vm, csa_addr,
- size);
- if (r) {
- DRM_ERROR("failed to allocate pts for static CSA, err=%d\n", r);
- amdgpu_vm_bo_rmv(adev, *bo_va);
- ttm_eu_backoff_reservation(, );
- return r;
- }
-
r = amdgpu_vm_bo_map(adev, *bo_va, csa_addr, 0, size,
AMDGPU_PTE_READABLE | AMDGPU_PTE_WRITEABLE |
AMDGPU_PTE_EXECUTABLE);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index d21dd2f369da..e141e3b13112 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -627,11 +627,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
switch (args->operation) {
case AMDGPU_VA_OP_MAP:
- r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
- args->map_size);
- if (r)
- goto error_backoff;
-
va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
r = amdgpu_vm_bo_map(adev, bo_va, args->va_address,
args->offset_in_bo, args->map_size,
@@ -647,11 +642,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
args->map_size);
break;
case AMDGPU_VA_OP_REPLACE:
- r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
-
Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
On 2019-02-04 3:17 p.m., Kuehling, Felix wrote:
> This may cause regressions in KFD if PT BO allocation can trigger
> eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
> context where we had temporarily removed the eviction fence. PT BO
> allocation in amdgpu_vm_bo_update is not protected like that.
>
> I vaguely remember looking into this last time you were working on our
> eviction fence code and thinking that most of the cases where we remove
> the eviction fence were no longer needed if fence synchronization
> happens through the amdgpu_sync-object API (rather than waiting on a
> reservation object directly). I think it's time I go and finally clean
> that up.
I'm looking at this now. It's not working as I was hoping.
>
> Do you know whether PT BO allocation would wait on the page-directory
> reservation object without the sync-object API anywhere?
It doesn't even matter. Buffer moves (anything calling amdgpu_sync_resv
with AMDGPU_FENCE_OWNER_UNDEFINED) are supposed to trigger eviction
fences. So page table BO allocation triggers eviction fences on the PD
reservation. I don't know how to avoid this other than by removing the
eviction fence while allocating PT BOs. With your changes this will be
potentially every time we map or unmap memory.
Any better ideas?
Regards,
Felix
>
> Regards,
> Felix
>
> On 2019-02-04 7:42 a.m., Christian König wrote:
>> Let's start to allocate VM PDs/PTs on demand instead of pre-allocating
>> them during mapping.
>>
>> Signed-off-by: Christian König
>> ---
>>.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -
>>drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 --
>>drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 --
>>drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +-
>>drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 -
>>5 files changed, 38 insertions(+), 126 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index d7b10d79f1de..2176c92f9377 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -492,12 +492,6 @@ static int add_bo_to_vm(struct amdgpu_device *adev,
>> struct kgd_mem *mem,
>> vm->process_info->eviction_fence,
>> NULL, NULL);
>>
>> -ret = amdgpu_vm_alloc_pts(adev, vm, va, amdgpu_bo_size(bo));
>> -if (ret) {
>> -pr_err("Failed to allocate pts, err=%d\n", ret);
>> -goto err_alloc_pts;
>> -}
>> -
>> ret = vm_validate_pt_pd_bos(vm);
>> if (ret) {
>> pr_err("validate_pt_pd_bos() failed\n");
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>> index 7e22be7ca68a..54dd02a898b9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
>> @@ -92,15 +92,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev,
>> struct amdgpu_vm *vm,
>> return -ENOMEM;
>> }
>>
>> -r = amdgpu_vm_alloc_pts(adev, (*bo_va)->base.vm, csa_addr,
>> -size);
>> -if (r) {
>> -DRM_ERROR("failed to allocate pts for static CSA, err=%d\n", r);
>> -amdgpu_vm_bo_rmv(adev, *bo_va);
>> -ttm_eu_backoff_reservation(, );
>> -return r;
>> -}
>> -
>> r = amdgpu_vm_bo_map(adev, *bo_va, csa_addr, 0, size,
>> AMDGPU_PTE_READABLE | AMDGPU_PTE_WRITEABLE |
>> AMDGPU_PTE_EXECUTABLE);
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> index d21dd2f369da..e141e3b13112 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> @@ -627,11 +627,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void
>> *data,
>>
>> switch (args->operation) {
>> case AMDGPU_VA_OP_MAP:
>> -r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
>> -args->map_size);
>> -if (r)
>> -goto error_backoff;
>> -
>> va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
>> r = amdgpu_vm_bo_map(adev, bo_va, args->va_address,
>> args->offset_in_bo, args->map_size,
>> @@ -647,11 +642,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void
>> *data,
>> args->map_size);
>> break;
>> case AMDGPU_VA_OP_REPLACE:
>> -r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
>> -args->map_size);
>> -if (r)
>> -goto error_backoff;
>> -
>> va_flags = amdgpu_gmc_get_pte_flags(adev,
Re: [PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
context where we had temporarily removed the eviction fence. PT BO
allocation in amdgpu_vm_bo_update is not protected like that.
I vaguely remember looking into this last time you were working on our
eviction fence code and thinking that most of the cases where we remove
the eviction fence were no longer needed if fence synchronization
happens through the amdgpu_sync-object API (rather than waiting on a
reservation object directly). I think it's time I go and finally clean
that up.
Do you know whether PT BO allocation would wait on the page-directory
reservation object without the sync-object API anywhere?
Regards,
Felix
On 2019-02-04 7:42 a.m., Christian König wrote:
> Let's start to allocate VM PDs/PTs on demand instead of pre-allocating
> them during mapping.
>
> Signed-off-by: Christian König
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 -
> 5 files changed, 38 insertions(+), 126 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index d7b10d79f1de..2176c92f9377 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -492,12 +492,6 @@ static int add_bo_to_vm(struct amdgpu_device *adev,
> struct kgd_mem *mem,
> vm->process_info->eviction_fence,
> NULL, NULL);
>
> - ret = amdgpu_vm_alloc_pts(adev, vm, va, amdgpu_bo_size(bo));
> - if (ret) {
> - pr_err("Failed to allocate pts, err=%d\n", ret);
> - goto err_alloc_pts;
> - }
> -
> ret = vm_validate_pt_pd_bos(vm);
> if (ret) {
> pr_err("validate_pt_pd_bos() failed\n");
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> index 7e22be7ca68a..54dd02a898b9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> @@ -92,15 +92,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev,
> struct amdgpu_vm *vm,
> return -ENOMEM;
> }
>
> - r = amdgpu_vm_alloc_pts(adev, (*bo_va)->base.vm, csa_addr,
> - size);
> - if (r) {
> - DRM_ERROR("failed to allocate pts for static CSA, err=%d\n", r);
> - amdgpu_vm_bo_rmv(adev, *bo_va);
> - ttm_eu_backoff_reservation(, );
> - return r;
> - }
> -
> r = amdgpu_vm_bo_map(adev, *bo_va, csa_addr, 0, size,
>AMDGPU_PTE_READABLE | AMDGPU_PTE_WRITEABLE |
>AMDGPU_PTE_EXECUTABLE);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index d21dd2f369da..e141e3b13112 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -627,11 +627,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void
> *data,
>
> switch (args->operation) {
> case AMDGPU_VA_OP_MAP:
> - r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
> - args->map_size);
> - if (r)
> - goto error_backoff;
> -
> va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
> r = amdgpu_vm_bo_map(adev, bo_va, args->va_address,
>args->offset_in_bo, args->map_size,
> @@ -647,11 +642,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void
> *data,
> args->map_size);
> break;
> case AMDGPU_VA_OP_REPLACE:
> - r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
> - args->map_size);
> - if (r)
> - goto error_backoff;
> -
> va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
> r = amdgpu_vm_bo_replace_map(adev, bo_va, args->va_address,
>args->offset_in_bo, args->map_size,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index f7d410a5d848..0b8a1aa56c4a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -504,47 +504,6 @@ static void amdgpu_vm_pt_next(struct amdgpu_device *adev,
> }
> }
>
> -/**
> - * amdgpu_vm_pt_first_leaf - get first leaf PD/PT
> - *
> - * @adev: amdgpu_device pointer
> - * @vm: amdgpu_vm
[PATCH 6/8] drm/amdgpu: allocate VM PDs/PTs on demand
Let's start to allocate VM PDs/PTs on demand instead of pre-allocating
them during mapping.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 136 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 3 -
5 files changed, 38 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index d7b10d79f1de..2176c92f9377 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -492,12 +492,6 @@ static int add_bo_to_vm(struct amdgpu_device *adev, struct
kgd_mem *mem,
vm->process_info->eviction_fence,
NULL, NULL);
- ret = amdgpu_vm_alloc_pts(adev, vm, va, amdgpu_bo_size(bo));
- if (ret) {
- pr_err("Failed to allocate pts, err=%d\n", ret);
- goto err_alloc_pts;
- }
-
ret = vm_validate_pt_pd_bos(vm);
if (ret) {
pr_err("validate_pt_pd_bos() failed\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 7e22be7ca68a..54dd02a898b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -92,15 +92,6 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
return -ENOMEM;
}
- r = amdgpu_vm_alloc_pts(adev, (*bo_va)->base.vm, csa_addr,
- size);
- if (r) {
- DRM_ERROR("failed to allocate pts for static CSA, err=%d\n", r);
- amdgpu_vm_bo_rmv(adev, *bo_va);
- ttm_eu_backoff_reservation(, );
- return r;
- }
-
r = amdgpu_vm_bo_map(adev, *bo_va, csa_addr, 0, size,
AMDGPU_PTE_READABLE | AMDGPU_PTE_WRITEABLE |
AMDGPU_PTE_EXECUTABLE);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index d21dd2f369da..e141e3b13112 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -627,11 +627,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
switch (args->operation) {
case AMDGPU_VA_OP_MAP:
- r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
- args->map_size);
- if (r)
- goto error_backoff;
-
va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
r = amdgpu_vm_bo_map(adev, bo_va, args->va_address,
args->offset_in_bo, args->map_size,
@@ -647,11 +642,6 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
args->map_size);
break;
case AMDGPU_VA_OP_REPLACE:
- r = amdgpu_vm_alloc_pts(adev, bo_va->base.vm, args->va_address,
- args->map_size);
- if (r)
- goto error_backoff;
-
va_flags = amdgpu_gmc_get_pte_flags(adev, args->flags);
r = amdgpu_vm_bo_replace_map(adev, bo_va, args->va_address,
args->offset_in_bo, args->map_size,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index f7d410a5d848..0b8a1aa56c4a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -504,47 +504,6 @@ static void amdgpu_vm_pt_next(struct amdgpu_device *adev,
}
}
-/**
- * amdgpu_vm_pt_first_leaf - get first leaf PD/PT
- *
- * @adev: amdgpu_device pointer
- * @vm: amdgpu_vm structure
- * @start: start addr of the walk
- * @cursor: state to initialize
- *
- * Start a walk and go directly to the leaf node.
- */
-static void amdgpu_vm_pt_first_leaf(struct amdgpu_device *adev,
- struct amdgpu_vm *vm, uint64_t start,
- struct amdgpu_vm_pt_cursor *cursor)
-{
- amdgpu_vm_pt_start(adev, vm, start, cursor);
- while (amdgpu_vm_pt_descendant(adev, cursor));
-}
-
-/**
- * amdgpu_vm_pt_next_leaf - get next leaf PD/PT
- *
- * @adev: amdgpu_device pointer
- * @cursor: current state
- *
- * Walk the PD/PT tree to the next leaf node.
- */
-static void amdgpu_vm_pt_next_leaf(struct amdgpu_device *adev,
- struct amdgpu_vm_pt_cursor *cursor)
-{
- amdgpu_vm_pt_next(adev, cursor);
- if (cursor->pfn != ~0ll)
- while (amdgpu_vm_pt_descendant(adev, cursor));
-}
-
-/**
- * for_each_amdgpu_vm_pt_leaf
