Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

2020-01-04 Thread Christian König 

Hi Alejandro,

yes I've implemented this, but I'm still hunting down some bugs with the 
new locks.


I will send out the patches on Monday even if I can't narrow that 
problem down further.


Regards,
Christian.

Am 03.01.20 um 05:20 schrieb Sierra Guiza, Alejandro (Alex):

[AMD Official Use Only - Internal Distribution Only]

Hi Christian,
I wonder if you had a chance to look into this warning.
Please let me know if there's something we could help with.

Regards,
Alejandro

-Original Message-
From: Christian König 
Sent: Thursday, December 12, 2019 2:52 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org; Yang, Philip 
; Sierra Guiza, Alejandro (Alex) 
Subject: Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

[CAUTION: External Email]

Hi Felix,

yeah, I've also found a corner case which would raise a warning now.

Need to rework how dependencies for the PTE update are generated.

Going to take care of this in the next few days, Christian.

Am 12.12.19 um 01:20 schrieb Felix Kuehling:

Hi Christian,

Alex started trying to invalidate PTEs in the MMU notifiers and we're
finding that we still need to reserve the VM reservation for
amdgpu_sync_resv in amdgpu_vm_sdma_prepare. Is that sync_resv still
needed now, given that VM fences aren't in that reservation object any
more?

Regards,
   Felix

On 2019-12-05 5:39, Christian König wrote:

When a BO is evicted immedially invalidate the mapped PTEs.

Signed-off-by: Christian König 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 -
   1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 839d6df394fc..e578113bfd55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2565,6 +2565,7 @@ void amdgpu_vm_bo_invalidate(struct
amdgpu_device *adev,
struct amdgpu_bo *bo, bool evicted)
   {
   struct amdgpu_vm_bo_base *bo_base;
+int r;
 /* shadow bo doesn't have bo base, its validation needs its
parent */
   if (bo->parent && bo->parent->shadow == bo) @@ -2572,8 +2573,22
@@ void amdgpu_vm_bo_invalidate(struct amdgpu_device *adev,
 for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
   struct amdgpu_vm *vm = bo_base->vm;
+struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+if (bo->tbo.type != ttm_bo_type_kernel) {
+struct amdgpu_bo_va *bo_va;
+
+bo_va = container_of(bo_base, struct amdgpu_bo_va,
+ base);
+r = amdgpu_vm_bo_update(adev, bo_va,
+bo->tbo.base.resv != resv);
+if (!r) {
+amdgpu_vm_bo_idle(bo_base);
+continue;
+}
+}
   -if (evicted && bo->tbo.base.resv ==
vm->root.base.bo->tbo.base.resv) {
+if (evicted && bo->tbo.base.resv == resv) {
   amdgpu_vm_bo_evicted(bo_base);
   continue;
   }

___
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

RE: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

2020-01-02 Thread Sierra Guiza, Alejandro (Alex) 
[AMD Official Use Only - Internal Distribution Only]

Hi Christian, 
I wonder if you had a chance to look into this warning. 
Please let me know if there's something we could help with.

Regards,
Alejandro

-Original Message-
From: Christian König  
Sent: Thursday, December 12, 2019 2:52 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org; 
Yang, Philip ; Sierra Guiza, Alejandro (Alex) 

Subject: Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

[CAUTION: External Email]

Hi Felix,

yeah, I've also found a corner case which would raise a warning now.

Need to rework how dependencies for the PTE update are generated.

Going to take care of this in the next few days, Christian.

Am 12.12.19 um 01:20 schrieb Felix Kuehling:
> Hi Christian,
>
> Alex started trying to invalidate PTEs in the MMU notifiers and we're 
> finding that we still need to reserve the VM reservation for 
> amdgpu_sync_resv in amdgpu_vm_sdma_prepare. Is that sync_resv still 
> needed now, given that VM fences aren't in that reservation object any 
> more?
>
> Regards,
>   Felix
>
> On 2019-12-05 5:39, Christian König wrote:
>> When a BO is evicted immedially invalidate the mapped PTEs.
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 -
>>   1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 839d6df394fc..e578113bfd55 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -2565,6 +2565,7 @@ void amdgpu_vm_bo_invalidate(struct 
>> amdgpu_device *adev,
>>struct amdgpu_bo *bo, bool evicted)
>>   {
>>   struct amdgpu_vm_bo_base *bo_base;
>> +int r;
>> /* shadow bo doesn't have bo base, its validation needs its 
>> parent */
>>   if (bo->parent && bo->parent->shadow == bo) @@ -2572,8 +2573,22 
>> @@ void amdgpu_vm_bo_invalidate(struct amdgpu_device *adev,
>> for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
>>   struct amdgpu_vm *vm = bo_base->vm;
>> +struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
>> +
>> +if (bo->tbo.type != ttm_bo_type_kernel) {
>> +struct amdgpu_bo_va *bo_va;
>> +
>> +bo_va = container_of(bo_base, struct amdgpu_bo_va,
>> + base);
>> +r = amdgpu_vm_bo_update(adev, bo_va,
>> +bo->tbo.base.resv != resv);
>> +if (!r) {
>> +amdgpu_vm_bo_idle(bo_base);
>> +continue;
>> +}
>> +}
>>   -if (evicted && bo->tbo.base.resv ==
>> vm->root.base.bo->tbo.base.resv) {
>> +if (evicted && bo->tbo.base.resv == resv) {
>>   amdgpu_vm_bo_evicted(bo_base);
>>   continue;
>>   }
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

2019-12-12 Thread Christian König 

Hi Philip,

that is an expected result. You can only invalidate page tables without 
holding the reservation lock.


What you do here is adding a new mapping and that one needs to allocate 
a new page tables and won't work like this.


Regards,
Christian.

Am 12.12.19 um 15:38 schrieb Philip Yang:

Hi Christian,

FYI, remove amdgpu_bo_reserve(root, true) before calling 
amdgpu_vm_bo_update_mapping, I got this warning backtrace:


    [  182.390072] WARNING: CPU: 12 PID: 4376 at

/home/yangp/git/compute_staging/kernel/drivers/gpu/drm/ttm/ttm_bo.c:1229
    ttm_bo_validate+0x14d/0x1b0 [ttm]
    [  182.390085] Modules linked in: fuse ip6table_filter ip6_tables
    iptable_filter amdgpu amd_iommu_v2 gpu_sched ast drm_vram_helper
    drm_ttm_helper ttm k10temp ip_tables x_tables i2c_piix4
    [  182.390123] CPU: 12 PID: 4376 Comm: kfdtest Tainted: G    W
    5.4.0-rc7-kfd-yangp #1
    [  182.390133] Hardware name: GIGABYTE MZ01-CE0-00/MZ01-CE0-00, 
BIOS F12

    08/05/2019
    [  182.390146] RIP: 0010:ttm_bo_validate+0x14d/0x1b0 [ttm]
    [  182.390153] Code: 40 ff 52 18 8b 44 24 04 e9 4f ff ff ff 48 8b 
87 20
    01 00 00 be ff ff ff ff 48 8d 78 60 e8 5b 3a e1 d4 85 c0 0f 85 e7 
fe ff
    ff <0f> 0b e9 e0 fe ff ff be 01 00 00 00 48 89 df e8 2f c4 ff ff 
e9 19

    [  182.390161] RSP: 0018:ab7a032f3990 EFLAGS: 00010246
    [  182.390166] RAX:  RBX: 943c59b37850 RCX:
    943c59b35000
    [  182.390171] RDX: 943c539daf00 RSI: 943c56fb31d8 RDI:
    943c539db790
    [  182.390178] RBP: 943c59b37830 R08: 0200 R09:
    
    [  182.390184] R10:  R11: 001fee0e R12:
    ab7a032f3a50
    [  182.390194] R13: 0200 R14: 943c59b37800 R15:
    
    [  182.390197] FS:  7f0d27f41780() GS:943c9e90()
    knlGS:
    [  182.390203] CS:  0010 DS:  ES:  CR0: 80050033
    [  182.390209] CR2: 7fba7a1010a0 CR3: 0007f2624000 CR4:
    003406e0
    [  182.390212] Call Trace:
    [  182.390219]  ? rcu_read_lock_sched_held+0x52/0x80
    [  182.390223]  ? _raw_spin_unlock+0x24/0x30
    [  182.390267]  ? amdgpu_bo_do_create+0x4d1/0x5d0 [amdgpu]
    [  182.390319]  amdgpu_vm_clear_bo+0x13d/0x3a0 [amdgpu]
    [  182.390371]  ? amdgpu_vm_num_entries+0x1e/0x70 [amdgpu]
    [  182.390424]  amdgpu_vm_update_ptes+0x561/0x5d0 [amdgpu]
    [  182.390480]  amdgpu_vm_bo_update_mapping+0xfd/0x130 [amdgpu]
    [  182.390530]  amdgpu_vm_bo_split_mapping+0x1ea/0x2c0 [amdgpu]
    [  182.390591]  svm_range_map_to_gpus+0x160/0x310 [amdgpu]
    [  182.390650]  kfd_register_svm+0xb8/0x2b0 [amdgpu]
    [  182.390708]  kfd_ioctl_register_svm+0xe8/0x110 [amdgpu]
    [  182.390765]  kfd_ioctl+0x232/0x3d0 [amdgpu]
    [  182.390823]  ? kfd_ioctl_get_process_apertures_new+0x310/0x310
    [amdgpu]
    [  182.390838]  ? selinux_file_ioctl+0x153/0x210
    [  182.390845]  do_vfs_ioctl+0xa2/0x6e0
    [  182.390854]  ksys_ioctl+0x70/0x80
    [  182.390862]  __x64_sys_ioctl+0x16/0x20
    [  182.390869]  do_syscall_64+0x4a/0x1b0
    [  182.390879]  entry_SYSCALL_64_after_hwframe+0x49/0xbe

Philip

On 2019-12-12 3:51 a.m., Christian König wrote:

Hi Felix,

yeah, I've also found a corner case which would raise a warning now.

Need to rework how dependencies for the PTE update are generated.

Going to take care of this in the next few days,
Christian.

Am 12.12.19 um 01:20 schrieb Felix Kuehling:

Hi Christian,

Alex started trying to invalidate PTEs in the MMU notifiers and 
we're finding that we still need to reserve the VM reservation for 
amdgpu_sync_resv in amdgpu_vm_sdma_prepare. Is that sync_resv still 
needed now, given that VM fences aren't in that reservation object 
any more?


Regards,
  Felix

On 2019-12-05 5:39, Christian König wrote:

When a BO is evicted immedially invalidate the mapped PTEs.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index 839d6df394fc..e578113bfd55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2565,6 +2565,7 @@ void amdgpu_vm_bo_invalidate(struct 
amdgpu_device *adev,

   struct amdgpu_bo *bo, bool evicted)
  {
  struct amdgpu_vm_bo_base *bo_base;
+    int r;
    /* shadow bo doesn't have bo base, its validation needs its 
parent */

  if (bo->parent && bo->parent->shadow == bo)
@@ -2572,8 +2573,22 @@ void amdgpu_vm_bo_invalidate(struct 
amdgpu_device *adev,

    for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
  struct amdgpu_vm *vm = bo_base->vm;
+    struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+    if (bo->tbo.type != ttm_bo_type_kernel) {
+    struct amdgpu_bo_va *bo_va;
+
+    bo_va = container_

Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

2019-12-12 Thread Philip Yang 

Hi Christian,

FYI, remove amdgpu_bo_reserve(root, true) before calling 
amdgpu_vm_bo_update_mapping, I got this warning backtrace:


[  182.390072] WARNING: CPU: 12 PID: 4376 at

/home/yangp/git/compute_staging/kernel/drivers/gpu/drm/ttm/ttm_bo.c:1229
ttm_bo_validate+0x14d/0x1b0 [ttm]
[  182.390085] Modules linked in: fuse ip6table_filter ip6_tables
iptable_filter amdgpu amd_iommu_v2 gpu_sched ast drm_vram_helper
drm_ttm_helper ttm k10temp ip_tables x_tables i2c_piix4
[  182.390123] CPU: 12 PID: 4376 Comm: kfdtest Tainted: GW
5.4.0-rc7-kfd-yangp #1
[  182.390133] Hardware name: GIGABYTE MZ01-CE0-00/MZ01-CE0-00, 
BIOS F12

08/05/2019
[  182.390146] RIP: 0010:ttm_bo_validate+0x14d/0x1b0 [ttm]
[  182.390153] Code: 40 ff 52 18 8b 44 24 04 e9 4f ff ff ff 48 8b 87 20
01 00 00 be ff ff ff ff 48 8d 78 60 e8 5b 3a e1 d4 85 c0 0f 85 e7 fe ff
ff <0f> 0b e9 e0 fe ff ff be 01 00 00 00 48 89 df e8 2f c4 ff ff e9 19
[  182.390161] RSP: 0018:ab7a032f3990 EFLAGS: 00010246
[  182.390166] RAX:  RBX: 943c59b37850 RCX:
943c59b35000
[  182.390171] RDX: 943c539daf00 RSI: 943c56fb31d8 RDI:
943c539db790
[  182.390178] RBP: 943c59b37830 R08: 0200 R09:

[  182.390184] R10:  R11: 001fee0e R12:
ab7a032f3a50
[  182.390194] R13: 0200 R14: 943c59b37800 R15:

[  182.390197] FS:  7f0d27f41780() GS:943c9e90()
knlGS:
[  182.390203] CS:  0010 DS:  ES:  CR0: 80050033
[  182.390209] CR2: 7fba7a1010a0 CR3: 0007f2624000 CR4:
003406e0
[  182.390212] Call Trace:
[  182.390219]  ? rcu_read_lock_sched_held+0x52/0x80
[  182.390223]  ? _raw_spin_unlock+0x24/0x30
[  182.390267]  ? amdgpu_bo_do_create+0x4d1/0x5d0 [amdgpu]
[  182.390319]  amdgpu_vm_clear_bo+0x13d/0x3a0 [amdgpu]
[  182.390371]  ? amdgpu_vm_num_entries+0x1e/0x70 [amdgpu]
[  182.390424]  amdgpu_vm_update_ptes+0x561/0x5d0 [amdgpu]
[  182.390480]  amdgpu_vm_bo_update_mapping+0xfd/0x130 [amdgpu]
[  182.390530]  amdgpu_vm_bo_split_mapping+0x1ea/0x2c0 [amdgpu]
[  182.390591]  svm_range_map_to_gpus+0x160/0x310 [amdgpu]
[  182.390650]  kfd_register_svm+0xb8/0x2b0 [amdgpu]
[  182.390708]  kfd_ioctl_register_svm+0xe8/0x110 [amdgpu]
[  182.390765]  kfd_ioctl+0x232/0x3d0 [amdgpu]
[  182.390823]  ? kfd_ioctl_get_process_apertures_new+0x310/0x310
[amdgpu]
[  182.390838]  ? selinux_file_ioctl+0x153/0x210
[  182.390845]  do_vfs_ioctl+0xa2/0x6e0
[  182.390854]  ksys_ioctl+0x70/0x80
[  182.390862]  __x64_sys_ioctl+0x16/0x20
[  182.390869]  do_syscall_64+0x4a/0x1b0
[  182.390879]  entry_SYSCALL_64_after_hwframe+0x49/0xbe

Philip

On 2019-12-12 3:51 a.m., Christian König wrote:

Hi Felix,

yeah, I've also found a corner case which would raise a warning now.

Need to rework how dependencies for the PTE update are generated.

Going to take care of this in the next few days,
Christian.

Am 12.12.19 um 01:20 schrieb Felix Kuehling:

Hi Christian,

Alex started trying to invalidate PTEs in the MMU notifiers and we're 
finding that we still need to reserve the VM reservation for 
amdgpu_sync_resv in amdgpu_vm_sdma_prepare. Is that sync_resv still 
needed now, given that VM fences aren't in that reservation object any 
more?


Regards,
  Felix

On 2019-12-05 5:39, Christian König wrote:

When a BO is evicted immedially invalidate the mapped PTEs.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index 839d6df394fc..e578113bfd55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2565,6 +2565,7 @@ void amdgpu_vm_bo_invalidate(struct 
amdgpu_device *adev,

   struct amdgpu_bo *bo, bool evicted)
  {
  struct amdgpu_vm_bo_base *bo_base;
+    int r;
    /* shadow bo doesn't have bo base, its validation needs its 
parent */

  if (bo->parent && bo->parent->shadow == bo)
@@ -2572,8 +2573,22 @@ void amdgpu_vm_bo_invalidate(struct 
amdgpu_device *adev,

    for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
  struct amdgpu_vm *vm = bo_base->vm;
+    struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+    if (bo->tbo.type != ttm_bo_type_kernel) {
+    struct amdgpu_bo_va *bo_va;
+
+    bo_va = container_of(bo_base, struct amdgpu_bo_va,
+ base);
+    r = amdgpu_vm_bo_update(adev, bo_va,
+    bo->tbo.base.resv != resv);
+    if (!r) {
+    amdgpu_vm_bo_idle(bo_base);
+    continue;
+    }
+    }
  -    if

Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

2019-12-12 Thread Christian König 

Hi Felix,

yeah, I've also found a corner case which would raise a warning now.

Need to rework how dependencies for the PTE update are generated.

Going to take care of this in the next few days,
Christian.

Am 12.12.19 um 01:20 schrieb Felix Kuehling:

Hi Christian,

Alex started trying to invalidate PTEs in the MMU notifiers and we're 
finding that we still need to reserve the VM reservation for 
amdgpu_sync_resv in amdgpu_vm_sdma_prepare. Is that sync_resv still 
needed now, given that VM fences aren't in that reservation object any 
more?


Regards,
  Felix

On 2019-12-05 5:39, Christian König wrote:

When a BO is evicted immedially invalidate the mapped PTEs.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index 839d6df394fc..e578113bfd55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2565,6 +2565,7 @@ void amdgpu_vm_bo_invalidate(struct 
amdgpu_device *adev,

   struct amdgpu_bo *bo, bool evicted)
  {
  struct amdgpu_vm_bo_base *bo_base;
+    int r;
    /* shadow bo doesn't have bo base, its validation needs its 
parent */

  if (bo->parent && bo->parent->shadow == bo)
@@ -2572,8 +2573,22 @@ void amdgpu_vm_bo_invalidate(struct 
amdgpu_device *adev,

    for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
  struct amdgpu_vm *vm = bo_base->vm;
+    struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+    if (bo->tbo.type != ttm_bo_type_kernel) {
+    struct amdgpu_bo_va *bo_va;
+
+    bo_va = container_of(bo_base, struct amdgpu_bo_va,
+ base);
+    r = amdgpu_vm_bo_update(adev, bo_va,
+    bo->tbo.base.resv != resv);
+    if (!r) {
+    amdgpu_vm_bo_idle(bo_base);
+    continue;
+    }
+    }
  -    if (evicted && bo->tbo.base.resv == 
vm->root.base.bo->tbo.base.resv) {

+    if (evicted && bo->tbo.base.resv == resv) {
  amdgpu_vm_bo_evicted(bo_base);
  continue;
  }


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

Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

2019-12-11 Thread Felix Kuehling 

Hi Christian,

Alex started trying to invalidate PTEs in the MMU notifiers and we're 
finding that we still need to reserve the VM reservation for 
amdgpu_sync_resv in amdgpu_vm_sdma_prepare. Is that sync_resv still 
needed now, given that VM fences aren't in that reservation object any more?


Regards,
  Felix

On 2019-12-05 5:39, Christian König wrote:

When a BO is evicted immedially invalidate the mapped PTEs.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 839d6df394fc..e578113bfd55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2565,6 +2565,7 @@ void amdgpu_vm_bo_invalidate(struct amdgpu_device *adev,
 struct amdgpu_bo *bo, bool evicted)
  {
struct amdgpu_vm_bo_base *bo_base;
+   int r;
  
  	/* shadow bo doesn't have bo base, its validation needs its parent */

if (bo->parent && bo->parent->shadow == bo)
@@ -2572,8 +2573,22 @@ void amdgpu_vm_bo_invalidate(struct amdgpu_device *adev,
  
  	for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {

struct amdgpu_vm *vm = bo_base->vm;
+   struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+   if (bo->tbo.type != ttm_bo_type_kernel) {
+   struct amdgpu_bo_va *bo_va;
+
+   bo_va = container_of(bo_base, struct amdgpu_bo_va,
+base);
+   r = amdgpu_vm_bo_update(adev, bo_va,
+   bo->tbo.base.resv != resv);
+   if (!r) {
+   amdgpu_vm_bo_idle(bo_base);
+   continue;
+   }
+   }
  
-		if (evicted && bo->tbo.base.resv == vm->root.base.bo->tbo.base.resv) {

+   if (evicted && bo->tbo.base.resv == resv) {
amdgpu_vm_bo_evicted(bo_base);
continue;
}

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

Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

2019-12-05 Thread Christian König 

Am 05.12.19 um 17:45 schrieb Felix Kuehling:

On 2019-12-05 8:39 a.m., Christian König wrote:

When a BO is evicted immedially invalidate the mapped PTEs.


I think you mentioned that this is just a proof of concept.


I also need this for immediately getting rid of mappings in DMA-buf 
based P2P.


I wouldn't submit the patch like this because it's overkill for VMs 
that don't want to use recoverable page faults and probably has a 
performance impact. I would do something specific to compute VMs in 
our MMU notifier.


I still need to test this, but I hope that it doesn't have that much 
impact on performance.


Regards,
Christian.



Regards,
  Felix



Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index 839d6df394fc..e578113bfd55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2565,6 +2565,7 @@ void amdgpu_vm_bo_invalidate(struct 
amdgpu_device *adev,

   struct amdgpu_bo *bo, bool evicted)
  {
  struct amdgpu_vm_bo_base *bo_base;
+    int r;
    /* shadow bo doesn't have bo base, its validation needs its 
parent */

  if (bo->parent && bo->parent->shadow == bo)
@@ -2572,8 +2573,22 @@ void amdgpu_vm_bo_invalidate(struct 
amdgpu_device *adev,

    for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
  struct amdgpu_vm *vm = bo_base->vm;
+    struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+    if (bo->tbo.type != ttm_bo_type_kernel) {
+    struct amdgpu_bo_va *bo_va;
+
+    bo_va = container_of(bo_base, struct amdgpu_bo_va,
+ base);
+    r = amdgpu_vm_bo_update(adev, bo_va,
+    bo->tbo.base.resv != resv);
+    if (!r) {
+    amdgpu_vm_bo_idle(bo_base);
+    continue;
+    }
+    }
  -    if (evicted && bo->tbo.base.resv == 
vm->root.base.bo->tbo.base.resv) {

+    if (evicted && bo->tbo.base.resv == resv) {
  amdgpu_vm_bo_evicted(bo_base);
  continue;
  }


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

Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

2019-12-05 Thread Felix Kuehling 

On 2019-12-05 8:39 a.m., Christian König wrote:

When a BO is evicted immedially invalidate the mapped PTEs.


I think you mentioned that this is just a proof of concept. I wouldn't 
submit the patch like this because it's overkill for VMs that don't want 
to use recoverable page faults and probably has a performance impact. I 
would do something specific to compute VMs in our MMU notifier.


Regards,
  Felix



Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 839d6df394fc..e578113bfd55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2565,6 +2565,7 @@ void amdgpu_vm_bo_invalidate(struct amdgpu_device *adev,
 struct amdgpu_bo *bo, bool evicted)
  {
struct amdgpu_vm_bo_base *bo_base;
+   int r;
  
  	/* shadow bo doesn't have bo base, its validation needs its parent */

if (bo->parent && bo->parent->shadow == bo)
@@ -2572,8 +2573,22 @@ void amdgpu_vm_bo_invalidate(struct amdgpu_device *adev,
  
  	for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {

struct amdgpu_vm *vm = bo_base->vm;
+   struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+   if (bo->tbo.type != ttm_bo_type_kernel) {
+   struct amdgpu_bo_va *bo_va;
+
+   bo_va = container_of(bo_base, struct amdgpu_bo_va,
+base);
+   r = amdgpu_vm_bo_update(adev, bo_va,
+   bo->tbo.base.resv != resv);
+   if (!r) {
+   amdgpu_vm_bo_idle(bo_base);
+   continue;
+   }
+   }
  
-		if (evicted && bo->tbo.base.resv == vm->root.base.bo->tbo.base.resv) {

+   if (evicted && bo->tbo.base.resv == resv) {
amdgpu_vm_bo_evicted(bo_base);
continue;
}

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