All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath
@ 2021-09-15  1:42 xinhui pan
  2021-09-15  3:02 ` Andrey Grodzovsky
  0 siblings, 1 reply; 3+ messages in thread
From: xinhui pan @ 2021-09-15  1:42 UTC (permalink / raw)
  To: amd-gfx
  Cc: alexander.deucher, christian.koenig, andrey.grodzovsky, xinhui pan

We hit soft hang while doing memory pressure test on one numa system.
After a qucik look, this is because kfd invalid/valid userptr memory
frequently with process_info lock hold.

perf top says below,
75.81%  [kernel]       [k] __srcu_read_unlock
 6.19%  [amdgpu]       [k] amdgpu_gmc_set_pte_pde
 3.56%  [kernel]       [k] __srcu_read_lock
 2.20%  [amdgpu]       [k] amdgpu_vm_cpu_update
 2.20%  [kernel]       [k] __sg_page_iter_dma_next
 2.15%  [drm]          [k] drm_dev_enter
 1.70%  [drm]          [k] drm_prime_sg_to_dma_addr_array
 1.18%  [kernel]       [k] __sg_alloc_table_from_pages
 1.09%  [drm]          [k] drm_dev_exit

So move drm_dev_enter/exit outside gmc code, instead let caller do it.
They are gart_unbind, gart_map, vm_cpu_update(already hold in its
caller) and gmc_init_pdb0(no need)

Signed-off-by: xinhui pan <xinhui.pan@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 11 +++++++++++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c  |  7 -------
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
index 76efd5f8950f..d7e4f4660acf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
@@ -34,6 +34,7 @@
 #include <asm/set_memory.h>
 #endif
 #include "amdgpu.h"
+#include <drm/drm_drv.h>
 
 /*
  * GART
@@ -230,12 +231,16 @@ int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
 	u64 page_base;
 	/* Starting from VEGA10, system bit must be 0 to mean invalid. */
 	uint64_t flags = 0;
+	int idx;
 
 	if (!adev->gart.ready) {
 		WARN(1, "trying to unbind memory from uninitialized GART !\n");
 		return -EINVAL;
 	}
 
+	if (!drm_dev_enter(&adev->ddev, &idx))
+		return 0;
+
 	t = offset / AMDGPU_GPU_PAGE_SIZE;
 	p = t / AMDGPU_GPU_PAGES_IN_CPU_PAGE;
 	for (i = 0; i < pages; i++, p++) {
@@ -254,6 +259,7 @@ int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
 	for (i = 0; i < adev->num_vmhubs; i++)
 		amdgpu_gmc_flush_gpu_tlb(adev, 0, i, 0);
 
+	drm_dev_exit(idx);
 	return 0;
 }
 
@@ -276,12 +282,16 @@ int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
 {
 	uint64_t page_base;
 	unsigned i, j, t;
+	int idx;
 
 	if (!adev->gart.ready) {
 		WARN(1, "trying to bind memory to uninitialized GART !\n");
 		return -EINVAL;
 	}
 
+	if (!drm_dev_enter(&adev->ddev, &idx))
+		return 0;
+
 	t = offset / AMDGPU_GPU_PAGE_SIZE;
 
 	for (i = 0; i < pages; i++) {
@@ -291,6 +301,7 @@ int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
 			page_base += AMDGPU_GPU_PAGE_SIZE;
 		}
 	}
+	drm_dev_exit(idx);
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 54f059501a33..e973488250e8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -31,7 +31,6 @@
 #include "amdgpu_ras.h"
 #include "amdgpu_xgmi.h"
 
-#include <drm/drm_drv.h>
 
 /**
  * amdgpu_gmc_pdb0_alloc - allocate vram for pdb0
@@ -153,10 +152,6 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, void *cpu_pt_addr,
 {
 	void __iomem *ptr = (void *)cpu_pt_addr;
 	uint64_t value;
-	int idx;
-
-	if (!drm_dev_enter(&adev->ddev, &idx))
-		return 0;
 
 	/*
 	 * The following is for PTE only. GART does not have PDEs.
@@ -165,8 +160,6 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, void *cpu_pt_addr,
 	value |= flags;
 	writeq(value, ptr + (gpu_page_idx * 8));
 
-	drm_dev_exit(idx);
-
 	return 0;
 }
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath
  2021-09-15  1:42 [PATCH] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath xinhui pan
@ 2021-09-15  3:02 ` Andrey Grodzovsky
       [not found]   ` <DM4PR12MB5165765C26B44904E030B1C587DB9@DM4PR12MB5165.namprd12.prod.outlook.com>
  0 siblings, 1 reply; 3+ messages in thread
From: Andrey Grodzovsky @ 2021-09-15  3:02 UTC (permalink / raw)
  To: xinhui pan, amd-gfx; +Cc: alexander.deucher, christian.koenig


On 2021-09-14 9:42 p.m., xinhui pan wrote:
> We hit soft hang while doing memory pressure test on one numa system.
> After a qucik look, this is because kfd invalid/valid userptr memory
> frequently with process_info lock hold.
>
> perf top says below,
> 75.81%  [kernel]       [k] __srcu_read_unlock


Do you have any idea why most of CPU cycles would be spent in SRCU 
unlock ? It's
not waiting on anything within this function and does some simple 
arithmetic inside
as far as I see.

>   6.19%  [amdgpu]       [k] amdgpu_gmc_set_pte_pde
>   3.56%  [kernel]       [k] __srcu_read_lock
>   2.20%  [amdgpu]       [k] amdgpu_vm_cpu_update
>   2.20%  [kernel]       [k] __sg_page_iter_dma_next
>   2.15%  [drm]          [k] drm_dev_enter
>   1.70%  [drm]          [k] drm_prime_sg_to_dma_addr_array
>   1.18%  [kernel]       [k] __sg_alloc_table_from_pages
>   1.09%  [drm]          [k] drm_dev_exit
>
> So move drm_dev_enter/exit outside gmc code, instead let caller do it.


Not clear from explanation here how the soft hang with process_info lock 
being hold
is related to to SRCU lock of drm_dev_enter/exit.


> They are gart_unbind, gart_map, vm_cpu_update(already hold in its
> caller)


Where in the caller ?


> and gmc_init_pdb0(no need)


Why no need ? Those guards protect from accessing MMIO ranges after
device is hot removed and hence they don't belong to him anymore. The
function above is also called during device resume from S3 and it's possible
to hot unplug device during S3 so this might be called with extracted device

Is it possible to run libdrm amdgpu test hot plug test suite on this 
change (before and after)
to verify if this actually breaks hot unplug ? The suite is committed 
into latest libdrm but disabled
until latest fixes from amd-staging-drm-next reach upstream drm-next. So 
to enable it this
code 
https://gitlab.freedesktop.org/mesa/drm/-/blob/main/tests/amdgpu/hotunplug_tests.c#L65
needs to be commented out.

Andrey


>
> Signed-off-by: xinhui pan <xinhui.pan@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 11 +++++++++++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c  |  7 -------
>   2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
> index 76efd5f8950f..d7e4f4660acf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
> @@ -34,6 +34,7 @@
>   #include <asm/set_memory.h>
>   #endif
>   #include "amdgpu.h"
> +#include <drm/drm_drv.h>
>   
>   /*
>    * GART
> @@ -230,12 +231,16 @@ int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
>   	u64 page_base;
>   	/* Starting from VEGA10, system bit must be 0 to mean invalid. */
>   	uint64_t flags = 0;
> +	int idx;
>   
>   	if (!adev->gart.ready) {
>   		WARN(1, "trying to unbind memory from uninitialized GART !\n");
>   		return -EINVAL;
>   	}
>   
> +	if (!drm_dev_enter(&adev->ddev, &idx))
> +		return 0;
> +
>   	t = offset / AMDGPU_GPU_PAGE_SIZE;
>   	p = t / AMDGPU_GPU_PAGES_IN_CPU_PAGE;
>   	for (i = 0; i < pages; i++, p++) {
> @@ -254,6 +259,7 @@ int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
>   	for (i = 0; i < adev->num_vmhubs; i++)
>   		amdgpu_gmc_flush_gpu_tlb(adev, 0, i, 0);
>   
> +	drm_dev_exit(idx);
>   	return 0;
>   }
>   
> @@ -276,12 +282,16 @@ int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
>   {
>   	uint64_t page_base;
>   	unsigned i, j, t;
> +	int idx;
>   
>   	if (!adev->gart.ready) {
>   		WARN(1, "trying to bind memory to uninitialized GART !\n");
>   		return -EINVAL;
>   	}
>   
> +	if (!drm_dev_enter(&adev->ddev, &idx))
> +		return 0;
> +
>   	t = offset / AMDGPU_GPU_PAGE_SIZE;
>   
>   	for (i = 0; i < pages; i++) {
> @@ -291,6 +301,7 @@ int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
>   			page_base += AMDGPU_GPU_PAGE_SIZE;
>   		}
>   	}
> +	drm_dev_exit(idx);
>   	return 0;
>   }
>   
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index 54f059501a33..e973488250e8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -31,7 +31,6 @@
>   #include "amdgpu_ras.h"
>   #include "amdgpu_xgmi.h"
>   
> -#include <drm/drm_drv.h>
>   
>   /**
>    * amdgpu_gmc_pdb0_alloc - allocate vram for pdb0
> @@ -153,10 +152,6 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, void *cpu_pt_addr,
>   {
>   	void __iomem *ptr = (void *)cpu_pt_addr;
>   	uint64_t value;
> -	int idx;
> -
> -	if (!drm_dev_enter(&adev->ddev, &idx))
> -		return 0;
>   
>   	/*
>   	 * The following is for PTE only. GART does not have PDEs.
> @@ -165,8 +160,6 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, void *cpu_pt_addr,
>   	value |= flags;
>   	writeq(value, ptr + (gpu_page_idx * 8));
>   
> -	drm_dev_exit(idx);
> -
>   	return 0;
>   }
>   

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 回复: [PATCH] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath
       [not found]   ` <DM4PR12MB5165765C26B44904E030B1C587DB9@DM4PR12MB5165.namprd12.prod.outlook.com>
@ 2021-09-15  4:13     ` Andrey Grodzovsky
  0 siblings, 0 replies; 3+ messages in thread
From: Andrey Grodzovsky @ 2021-09-15  4:13 UTC (permalink / raw)
  To: Pan, Xinhui, amd-gfx list; +Cc: Christian.Koenig, Alexander.Deucher

I think you missed 'reply all' so bringing  back to public

On 2021-09-14 11:40 p.m., Pan, Xinhui wrote:
> [AMD Official Use Only]
>
> perf says it is the lock   addl   $0x0,-0x4(%rsp)
> details is below. the contention is huge maybe.


Yes - that makes sense to me too as long as the lock here is some kind 
of busy wait (spinlock)
because for mutex you would sleep and hence not count toward CPU time 
spent here.


>
>         │    void __srcu_read_unlock(struct srcu_struct *ssp, int idx)
>         │    {
>         │    → callq  __fentry__
>         │      push   %rbp
>    0.46 │      mov    %rsp,%rbp
>         │    smp_mb(); /* C */  /* Avoid leaking the critical section. */
>   99.10 │      lock   addl   $0x0,-0x4(%rsp)
>         │    this_cpu_inc(ssp->sda->srcu_unlock_count[idx]);
>    0.01 │      movslq %esi,%rsi
>         │      mov    0xc500(%rdi),%rax
>    0.22 │      incq   %gs:0x10(%rax,%rsi,8)
>         │    }
>         │      pop    %rbp
>    0.21 │    ← retq
>
>
>
> as for soft lockup, kfd ioctl would try lock process_info which is hold by kernel restrore thread and it runs for a long time. maybe some debug logs below helps.
>
> [  637.463063] XH: lock &process_info->lock for 24s
> [  637.463070] CPU: 42 PID: 450 Comm: kworker/42:1 Not tainted 5.13.0+ #5
> [  637.463072] Hardware name: Supermicro SYS-4028GR-TRT2/X10DRG-OT+-CPU, BIOS 2.0c 07/21/2017
> [  637.463074] Workqueue: events amdgpu_amdkfd_restore_userptr_worker [amdgpu]
> [  637.463416] Call Trace:
> [  637.463418]  dump_stack+0x7d/0x9c
> [  637.463422]  mutex_unlock_xh+0x7e/0xb0 [amdgpu]
> [  637.463652]  amdgpu_amdkfd_restore_userptr_worker+0x470/0x790 [amdgpu]
> [  637.463878]  process_one_work+0x236/0x420
> [  637.463882]  worker_thread+0x34/0x400
> [  637.463884]  ? process_one_work+0x420/0x420
> [  637.463887]  kthread+0x126/0x140
> [  637.463890]  ? kthread_park+0x90/0x90
> [  637.463892]  ret_from_fork+0x22/0x30
> [  637.463908]          mutex_lock_xh+0x32/0x60 [amdgpu]
> [  637.464134]          amdgpu_amdkfd_restore_userptr_worker+0xd1/0x790 [amdgpu]
> [  637.464360]          process_one_work+0x236/0x420
> [  637.464362]          worker_thread+0x34/0x400
> [  637.464364]          kthread+0x126/0x140
> [  637.464366]          ret_from_fork+0x22/0x30
> [  637.468717] XH: lock &p->mutex for 24s
> [  637.468722] CPU: 14 PID: 2104 Comm: kfdtest Not tainted 5.13.0+ #5
> [  637.468726] Hardware name: Supermicro SYS-4028GR-TRT2/X10DRG-OT+-CPU, BIOS 2.0c 07/21/2017
> [  637.468728] Call Trace:
> [  637.468730]  dump_stack+0x7d/0x9c
> [  637.468735]  mutex_unlock_xh+0x7e/0xb0 [amdgpu]
> [  637.469251]  kfd_ioctl_map_memory_to_gpu+0x38a/0x5a0 [amdgpu]
> [  637.469780]  kfd_ioctl+0x51f/0x6f0 [amdgpu]
> [  637.470308]  ? kfd_ioctl_unmap_memory_from_gpu+0x520/0x520 [amdgpu]
> [  637.470836]  ? __vm_munmap+0xa0/0x130
> [  637.470842]  __x64_sys_ioctl+0x96/0xd0
> [  637.470849]  ? exit_to_user_mode_prepare+0x32/0x1d0
> [  637.470858]  do_syscall_64+0x3c/0xb0
> [  637.470864]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [  637.470869] RIP: 0033:0x7f3e6bac3317
> [  637.470875] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48
> [  637.470879] RSP: 002b:00007ffcfea0f668 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
> [  637.470884] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f3e6bac3317
> [  637.470887] RDX: 00007ffcfea0f6f0 RSI: 00000000c0184b18 RDI: 0000000000000003
> [  637.470889] RBP: 00007ffcfea0f6a0 R08: 0000000000000000 R09: 0000000000000000
> [  637.470892] R10: 000055afe3e7a010 R11: 0000000000000202 R12: 000055afe2e4f3ba
> [  637.470894] R13: 0000000000000000 R14: 0000000000000021 R15: 0000000000000000
> [  637.470919]          mutex_lock_xh+0x32/0x60 [amdgpu]
> [  637.471455]          kfd_ioctl_map_memory_to_gpu+0x1eb/0x5a0 [amdgpu]
> [  637.472006]          kfd_ioctl+0x51f/0x6f0 [amdgpu]
> [  637.472544]          __x64_sys_ioctl+0x96/0xd0
> [  637.472550]          do_syscall_64+0x3c/0xb0
> [  637.472554]          entry_SYSCALL_64_after_hwframe+0x44/0xae
>
>
>
> vm_cpu_update is called by amdgpu_vm_bo_update_mapping which already calls drm_dev_enter/exit.


What about other callers of vm_cpu_update such as amdgpu_vm_update_pde and
amdgpu_vm_clear_bo ?

Also in general - I am not clear what code path that uses 
amdgpu_gmc_set_pte_pde
was the problematic one and this change fixed it ? Is it one of the two 
I mentioned above ?

Andrey


> yes, gmc_init_pdb0 could be called during s3, I will add the enter/exit there too.
> I will do the plug/unplug test to verfiy it.
>
> _______________________________________
> 发件人: Grodzovsky, Andrey <Andrey.Grodzovsky@amd.com>
> 发送时间: 2021年9月15日 11:02
> 收件人: Pan, Xinhui; amd-gfx@lists.freedesktop.org
> 抄送: Deucher, Alexander; Koenig, Christian
> 主题: Re: [PATCH] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath
>
>
> On 2021-09-14 9:42 p.m., xinhui pan wrote:
>> We hit soft hang while doing memory pressure test on one numa system.
>> After a qucik look, this is because kfd invalid/valid userptr memory
>> frequently with process_info lock hold.
>>
>> perf top says below,
>> 75.81%  [kernel]       [k] __srcu_read_unlock
>
> Do you have any idea why most of CPU cycles would be spent in SRCU
> unlock ? It's
> not waiting on anything within this function and does some simple
> arithmetic inside
> as far as I see.
>
>>    6.19%  [amdgpu]       [k] amdgpu_gmc_set_pte_pde
>>    3.56%  [kernel]       [k] __srcu_read_lock
>>    2.20%  [amdgpu]       [k] amdgpu_vm_cpu_update
>>    2.20%  [kernel]       [k] __sg_page_iter_dma_next
>>    2.15%  [drm]          [k] drm_dev_enter
>>    1.70%  [drm]          [k] drm_prime_sg_to_dma_addr_array
>>    1.18%  [kernel]       [k] __sg_alloc_table_from_pages
>>    1.09%  [drm]          [k] drm_dev_exit
>>
>> So move drm_dev_enter/exit outside gmc code, instead let caller do it.
>
> Not clear from explanation here how the soft hang with process_info lock
> being hold
> is related to to SRCU lock of drm_dev_enter/exit.
>
>
>> They are gart_unbind, gart_map, vm_cpu_update(already hold in its
>> caller)
>
> Where in the caller ?
>
>
>> and gmc_init_pdb0(no need)
>
> Why no need ? Those guards protect from accessing MMIO ranges after
> device is hot removed and hence they don't belong to him anymore. The
> function above is also called during device resume from S3 and it's possible
> to hot unplug device during S3 so this might be called with extracted device
>
> Is it possible to run libdrm amdgpu test hot plug test suite on this
> change (before and after)
> to verify if this actually breaks hot unplug ? The suite is committed
> into latest libdrm but disabled
> until latest fixes from amd-staging-drm-next reach upstream drm-next. So
> to enable it this
> code
> https://gitlab.freedesktop.org/mesa/drm/-/blob/main/tests/amdgpu/hotunplug_tests.c#L65
> needs to be commented out.
>
> Andrey
>
>
>> Signed-off-by: xinhui pan <xinhui.pan@amd.com>
>> ---
>>    drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 11 +++++++++++
>>    drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c  |  7 -------
>>    2 files changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> index 76efd5f8950f..d7e4f4660acf 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
>> @@ -34,6 +34,7 @@
>>    #include <asm/set_memory.h>
>>    #endif
>>    #include "amdgpu.h"
>> +#include <drm/drm_drv.h>
>>
>>    /*
>>     * GART
>> @@ -230,12 +231,16 @@ int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
>>        u64 page_base;
>>        /* Starting from VEGA10, system bit must be 0 to mean invalid. */
>>        uint64_t flags = 0;
>> +     int idx;
>>
>>        if (!adev->gart.ready) {
>>                WARN(1, "trying to unbind memory from uninitialized GART !\n");
>>                return -EINVAL;
>>        }
>>
>> +     if (!drm_dev_enter(&adev->ddev, &idx))
>> +             return 0;
>> +
>>        t = offset / AMDGPU_GPU_PAGE_SIZE;
>>        p = t / AMDGPU_GPU_PAGES_IN_CPU_PAGE;
>>        for (i = 0; i < pages; i++, p++) {
>> @@ -254,6 +259,7 @@ int amdgpu_gart_unbind(struct amdgpu_device *adev, uint64_t offset,
>>        for (i = 0; i < adev->num_vmhubs; i++)
>>                amdgpu_gmc_flush_gpu_tlb(adev, 0, i, 0);
>>
>> +     drm_dev_exit(idx);
>>        return 0;
>>    }
>>
>> @@ -276,12 +282,16 @@ int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
>>    {
>>        uint64_t page_base;
>>        unsigned i, j, t;
>> +     int idx;
>>
>>        if (!adev->gart.ready) {
>>                WARN(1, "trying to bind memory to uninitialized GART !\n");
>>                return -EINVAL;
>>        }
>>
>> +     if (!drm_dev_enter(&adev->ddev, &idx))
>> +             return 0;
>> +
>>        t = offset / AMDGPU_GPU_PAGE_SIZE;
>>
>>        for (i = 0; i < pages; i++) {
>> @@ -291,6 +301,7 @@ int amdgpu_gart_map(struct amdgpu_device *adev, uint64_t offset,
>>                        page_base += AMDGPU_GPU_PAGE_SIZE;
>>                }
>>        }
>> +     drm_dev_exit(idx);
>>        return 0;
>>    }
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>> index 54f059501a33..e973488250e8 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>> @@ -31,7 +31,6 @@
>>    #include "amdgpu_ras.h"
>>    #include "amdgpu_xgmi.h"
>>
>> -#include <drm/drm_drv.h>
>>
>>    /**
>>     * amdgpu_gmc_pdb0_alloc - allocate vram for pdb0
>> @@ -153,10 +152,6 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, void *cpu_pt_addr,
>>    {
>>        void __iomem *ptr = (void *)cpu_pt_addr;
>>        uint64_t value;
>> -     int idx;
>> -
>> -     if (!drm_dev_enter(&adev->ddev, &idx))
>> -             return 0;
>>
>>        /*
>>         * The following is for PTE only. GART does not have PDEs.
>> @@ -165,8 +160,6 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, void *cpu_pt_addr,
>>        value |= flags;
>>        writeq(value, ptr + (gpu_page_idx * 8));
>>
>> -     drm_dev_exit(idx);
>> -
>>        return 0;
>>    }
>>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-09-15  4:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-15  1:42 [PATCH] drm/amdgpu: Put drm_dev_enter/exit outside hot codepath xinhui pan
2021-09-15  3:02 ` Andrey Grodzovsky
     [not found]   ` <DM4PR12MB5165765C26B44904E030B1C587DB9@DM4PR12MB5165.namprd12.prod.outlook.com>
2021-09-15  4:13     ` 回复: " Andrey Grodzovsky

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.