Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

I think I'm missing something.
Actually I'm thinking more that I'm missing something :) But the result 
is the same.



You're raising some potential problems that I think must be about swapping out 
page tables that don't have fences on them (otherwise they wouldn't be evicted) 
and that are managed by HMM.
Wait a second, exactly that's the point. The page tables do have fences 
on them when they are evicted.


We currently just pipeline the eviction so that it happens only after 
those fences are signaled.



I think we should have a phone call to sort this out.

Yeah, that is a really good idea.

Regards,
Christian.

Am 13.09.2018 um 06:45 schrieb Kuehling, Felix:

I think I'm missing something. I thought the whole discussion we were having 
about tracking current and future locations of page tables was about swapping 
out page tables that are managed by HMM. We currently do swap out page tables 
that don't have fence on them and that are not managed by HMM. And pipelining 
that is not a problem today.

You're raising some potential problems that I think must be about swapping out 
page tables that don't have fences on them (otherwise they wouldn't be evicted) 
and that are managed by HMM. If there is no fence on the page table, no engine 
that can't handle page faults can depend on the page tables. So we can discard 
the contents and set the parent page directory entry to invalid. Setting the 
parent PDE needs to be synchronous so that the GPU doesn't try to access a page 
table that is no longer there. No pipelining, no problem.

Then you came back with an argument "what about engines that don't support page 
faults". Those engines can't use memory mapped by HMM anyway. And they can't be 
evicted while they have a fence on them that indicates active usage by such an engine.

You seem to see some problems that require not pipelining page table evictions. 
I still don't understand what the problem is. I think we should have a phone 
call to sort this out.

A few more comments inline, but I think we're misunderstanding each other ...


5. The new system memory location of the page table is noted in its BO.

You mean in the parent page table? You can just invalidate the entry in
the parent page table and let it fault.

I'm repeating myself, but exactly that is what won't work.

See we still have engines which can't handle page faults which uses
the same VM at the same time. This means that we can't just fault in
page tables.

And I don't understand why that is a problem. Those clients rely on
fences to keep their BOs resident, including the page tables. Are you
planning to change that?

No, but how do you want to swap out page tables when there is a fence added?

I don't. That's my point. If the page table has fences on it, it can't be 
swapped out. So there is no problem.


Or do you want to stop adding fences to page tables for engines with
recoverable faults?

Yes, that was my assumption, coming from a KFD perspective where with HMM we 
want to get away from our eviction fences that enforce BO residency, including 
page tables. Right now signaling an eviction fence means stopping user mode 
queues. We want to stop doing that.

If page tables get evicted, that's fine as long as those virtual addresses 
aren't accessed. Once an access happens, the page table needs to be restored or 
recreated. Once that's done, the retrying hardware block will get a successful 
translation and continue executing.


I think that is completely unrealistic considering the performance
penalty of faults.

I agree that evicting a page table that's in active use is bad. For amdgpu_cs 
you can prevent that with a fence, no problem.

But a fence is not a good way to prevent that for KFD, because it forces us to 
keep using our eviction fence and preempting user mode queues on evictions. You 
see, the eviction fence does not prevent the page table from being evicted, but 
it forces us to preempt all our queues when an eviction happens. That is a 
worse performance penalty than dealing with a page fault because the page fault 
is much more selective. A page fault can interrupt a compute shader at wave 
granularity. An preemption interrupts compute shaders with process granularity 
and at much longer time scales.

For KFD I would try to find a better way to avoid evictions of page tables, 
maybe by bumping them up in the LRU at appropriate times. But even without any 
such improvements, page faults are still better for KFD than the current 
eviction-fence-based approach.

Regards,
   Felix


At least for currently available hardware we should limit page faults to
be used in as few cases as possible, e.g. SVM and userptr.

Regards,
Christian.


From: Koenig, Christian
Sent: Wednesday, September 12, 2018 11:59 AM
To: Kuehling, Feli

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Kuehling, Felix]

I think I'm missing something. I thought the whole discussion we were having 
about tracking current and future locations of page tables was about swapping 
out page tables that are managed by HMM. We currently do swap out page tables 
that don't have fence on them and that are not managed by HMM. And pipelining 
that is not a problem today.

You're raising some potential problems that I think must be about swapping out 
page tables that don't have fences on them (otherwise they wouldn't be evicted) 
and that are managed by HMM. If there is no fence on the page table, no engine 
that can't handle page faults can depend on the page tables. So we can discard 
the contents and set the parent page directory entry to invalid. Setting the 
parent PDE needs to be synchronous so that the GPU doesn't try to access a page 
table that is no longer there. No pipelining, no problem.

Then you came back with an argument "what about engines that don't support page 
faults". Those engines can't use memory mapped by HMM anyway. And they can't be 
evicted while they have a fence on them that indicates active usage by such an 
engine.

You seem to see some problems that require not pipelining page table evictions. 
I still don't understand what the problem is. I think we should have a phone 
call to sort this out.

A few more comments inline, but I think we're misunderstanding each other ...

>>>>> 5. The new system memory location of the page table is noted in its BO.
>>>> You mean in the parent page table? You can just invalidate the entry in
>>>> the parent page table and let it fault.
>>> I'm repeating myself, but exactly that is what won't work.
>>>
>>> See we still have engines which can't handle page faults which uses
>>> the same VM at the same time. This means that we can't just fault in
>>> page tables.
>> And I don't understand why that is a problem. Those clients rely on
>> fences to keep their BOs resident, including the page tables. Are you
>> planning to change that?
> 
> No, but how do you want to swap out page tables when there is a fence added?

I don't. That's my point. If the page table has fences on it, it can't be 
swapped out. So there is no problem.

> 
> Or do you want to stop adding fences to page tables for engines with
> recoverable faults?

Yes, that was my assumption, coming from a KFD perspective where with HMM we 
want to get away from our eviction fences that enforce BO residency, including 
page tables. Right now signaling an eviction fence means stopping user mode 
queues. We want to stop doing that.

If page tables get evicted, that's fine as long as those virtual addresses 
aren't accessed. Once an access happens, the page table needs to be restored or 
recreated. Once that's done, the retrying hardware block will get a successful 
translation and continue executing.

> 
> I think that is completely unrealistic considering the performance
> penalty of faults.

I agree that evicting a page table that's in active use is bad. For amdgpu_cs 
you can prevent that with a fence, no problem.

But a fence is not a good way to prevent that for KFD, because it forces us to 
keep using our eviction fence and preempting user mode queues on evictions. You 
see, the eviction fence does not prevent the page table from being evicted, but 
it forces us to preempt all our queues when an eviction happens. That is a 
worse performance penalty than dealing with a page fault because the page fault 
is much more selective. A page fault can interrupt a compute shader at wave 
granularity. An preemption interrupts compute shaders with process granularity 
and at much longer time scales.

For KFD I would try to find a better way to avoid evictions of page tables, 
maybe by bumping them up in the LRU at appropriate times. But even without any 
such improvements, page faults are still better for KFD than the current 
eviction-fence-based approach.

Regards,
  Felix

> 
> At least for currently available hardware we should limit page faults to
> be used in as few cases as possible, e.g. SVM and userptr.
> 
> Regards,
> Christian.

From: Koenig, Christian
Sent: Wednesday, September 12, 2018 11:59 AM
To: Kuehling, Felix; Zeng, Oak; Oak Zeng; amd-gfx@lists.freedesktop.org; Yang, 
Philip
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Am 12.09.2018 um 17:29 schrieb Felix Kuehling:
> On 2018-09-12 02:56 AM, Christian König wrote:
>> Am 12.09.2018 um 00:00 schrieb Felix Kuehling:
>>> On 2018-09-11 03:19 AM, Christian König wrote:
>>>> Hi Felix,
>>>>
>>>> let me try to explain the problem on an example:
>>>>
>>>

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

update page tables when there is no more
user
mode context that cares about them? Is this just to allow pending
work
to complete after the user mode context is gone? To prevent hangs?

The problem I'm see is that we still don't have a reliable way of
killing a command submission while making sure that no more
faults of
it are in the flight.

E.g. the HWS has a function to kill a running job on the hardware,
but that only works for compute and there is no way of telling when
that operation has finished.

But Oak has already convinced me that we should probably work on
that
instead of trying to keep the VM alive as long as possible.

Regards,
Christian.

Am 08.09.2018 um 02:27 schrieb Felix Kuehling:

Hi Christian,

I'm not sure I get your point here.

As I understand it, the amdgpu_vm structure represents the user
mode VM
context. It has the pointers to the root page directory and the
rest of
the page table hierarchy. If there is no amdgpu_vm, there is no
user
mode context that cares about the page tables.

If we leave the page table pointers in the amdgpu_vm, then handling
faults after the VM is destroyed is pointless. We can't find the
page
tables and we can't update them, so there is nothing we can do in
response to VM faults.

So I'm guessing that you want to move the page table pointers
into a
different structure that exists half-independently of the VM. It
would
be created when the VM is created (that's where we currently
allocate
the PASID) but can be destroyed slightly later.

But why do you want to update page tables when there is no more
user
mode context that cares about them? Is this just to allow pending
work
to complete after the user mode context is gone? To prevent hangs?

Regards,
  Felix

On 2018-09-10 07:20 AM, Christian König wrote:

Am I right that the handling of page fault need a valid VM?

No, exactly that view is incorrect.

The VM is meant to be a memory management structure of page
tables and
is completely pointless fault processing because it represent the
future state of the page tables and not the current one.

What we need for fault processing is a new structure build around
PASIDs which is feed by the with addresses when page tables are
moved
around.

Alternatively I hope that we can use the SDMA to walk the page
tables
and update the required entries by just using the address.

Regards,
Christian.

Am 07.09.2018 um 16:55 schrieb Zeng, Oak:

Hi Christian,


What is the value of delay the destroy of hash to after vm is
destroyed? Since vm is destroyed, you basically don’t have enough
information to paging in the correct page to gpuvm. Am I right
that
the handling of page fault need a valid VM? For example, you
need the
VM to get the corresponding physical address of the faulty page.


After vm is destroyed, the retry interrupt can be directly
discard as
you can’t find vm through pasid. You can think this is also one
kind
of prescreen.


So I am stand for the point that, there is no need to delay the
destroy of hash to after vm is destroyed. Prescreening hash
can be
destroyed at the time of vm_fini.


Thanks,

Oak


*From:*Christian König 
*Sent:* Friday, September 07, 2018 4:39 AM
*To:* Zeng, Oak ; Oak Zeng
;
amd-gfx@lists.freedesktop.org
*Cc:* Zeng, Oak 
*Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to
amdgpu vm


Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was
not a
suggestion but rather a must have.

The VM structures must be destroyed while the processing is still
ongoing, or otherwise we would not have a clean OOM handling.

The IDR for PASID lockup can be put into amdgpu_ids.c, you can
just
replace the IDA already used there with an IDR.

Since the PASID is already freed up delayed we should have the
grace
period for interrupt processing included. If that still isn't
sufficient we can still add some delayed work for this.

Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:

    Hi Christian,

    In this implementation, fault hash is made per vm, not per
pasid
    as suggested, based on below considerations:

  * Delay the destroy of hash introduces more effort like
how to
    set the proper grace period after which no retry
interrupt
    will be generated. We want to avoid those complication
if we
    can.
  * The  problem of the per vm implementation is that it
is hard
    to delay the destroy of fault hash, because when vm is
    destroyed, prescreen function won't be able to
retrieve the
    fault hash. But in this case, the prescreen
function can
    either let the interrupt go through (to gmc) or ignore
it.
    From this perspective, it is not very necessary to
delay the
    destroy of hash table.
  * On the other hand, since ASICs after vega10 have the
HW CAM
    feature. So the SW IV prescreen is only useful for
vega10.
    For all the HW

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Felix Kuehling]

dating PTEs with new
>>>> valid addresses, it's asynchronous. But the GPU will continue retrying
>>>> on the invalid entry until SDMA finishes. So it's also implicitly
>>>> synchronized on the GPU side.
>>>>
>>>> Regards,
>>>>     Felix
>>>>
>>>>
>>>> On 2018-09-10 05:42 AM, Christian König wrote:
>>>>> Hi Felix & Oak,
>>>>>
>>>>> over the weekend I had the idea that we could just use the shadow BOs
>>>>> to have the current state in a page fault. They are GTT BOs and CPU
>>>>> accessible anyway.
>>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>> Am 08.09.2018 um 09:34 schrieb Christian König:
>>>>>> Hi Felix,
>>>>>>
>>>>>>> But why do you want to update page tables when there is no more
>>>>>>> user
>>>>>>> mode context that cares about them? Is this just to allow pending
>>>>>>> work
>>>>>>> to complete after the user mode context is gone? To prevent hangs?
>>>>>> The problem I'm see is that we still don't have a reliable way of
>>>>>> killing a command submission while making sure that no more
>>>>>> faults of
>>>>>> it are in the flight.
>>>>>>
>>>>>> E.g. the HWS has a function to kill a running job on the hardware,
>>>>>> but that only works for compute and there is no way of telling when
>>>>>> that operation has finished.
>>>>>>
>>>>>> But Oak has already convinced me that we should probably work on
>>>>>> that
>>>>>> instead of trying to keep the VM alive as long as possible.
>>>>>>
>>>>>> Regards,
>>>>>> Christian.
>>>>>>
>>>>>> Am 08.09.2018 um 02:27 schrieb Felix Kuehling:
>>>>>>> Hi Christian,
>>>>>>>
>>>>>>> I'm not sure I get your point here.
>>>>>>>
>>>>>>> As I understand it, the amdgpu_vm structure represents the user
>>>>>>> mode VM
>>>>>>> context. It has the pointers to the root page directory and the
>>>>>>> rest of
>>>>>>> the page table hierarchy. If there is no amdgpu_vm, there is no
>>>>>>> user
>>>>>>> mode context that cares about the page tables.
>>>>>>>
>>>>>>> If we leave the page table pointers in the amdgpu_vm, then handling
>>>>>>> faults after the VM is destroyed is pointless. We can't find the
>>>>>>> page
>>>>>>> tables and we can't update them, so there is nothing we can do in
>>>>>>> response to VM faults.
>>>>>>>
>>>>>>> So I'm guessing that you want to move the page table pointers
>>>>>>> into a
>>>>>>> different structure that exists half-independently of the VM. It
>>>>>>> would
>>>>>>> be created when the VM is created (that's where we currently
>>>>>>> allocate
>>>>>>> the PASID) but can be destroyed slightly later.
>>>>>>>
>>>>>>> But why do you want to update page tables when there is no more
>>>>>>> user
>>>>>>> mode context that cares about them? Is this just to allow pending
>>>>>>> work
>>>>>>> to complete after the user mode context is gone? To prevent hangs?
>>>>>>>
>>>>>>> Regards,
>>>>>>>  Felix
>>>>>>>
>>>>>>> On 2018-09-10 07:20 AM, Christian König wrote:
>>>>>>>>> Am I right that the handling of page fault need a valid VM?
>>>>>>>> No, exactly that view is incorrect.
>>>>>>>>
>>>>>>>> The VM is meant to be a memory management structure of page
>>>>>>>> tables and
>>>>>>>> is completely pointless fault processing because it represent the
>>>>>>>> future state of the page tables and not the current one.
>>>>>>>>
>>>>>>>> What we need for f

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

Am 07.09.2018 um 05:28 schrieb Oak Zeng:

In stead of share one fault hash table per device, make it
per vm. This can avoid inter-process lock issue when fault
hash table is full.

Change-Id: I5d1281b7c41eddc8e26113e010516557588d3708
Signed-off-by: Oak Zeng 
Suggested-by: Christian Konig 
Suggested-by: Felix Kuehling 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c |  75 
  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h |  10 
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 102 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  12 
  drivers/gpu/drm/amd/amdgpu/vega10_ih.c |  38 +---
  5 files changed, 127 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index 06373d4..4ed8621 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -197,78 +197,3 @@ int amdgpu_ih_process(struct amdgpu_device *adev)
return IRQ_HANDLED;
  }
  
-/**

- * amdgpu_ih_add_fault - Add a page fault record
- *
- * @adev: amdgpu device pointer
- * @key: 64-bit encoding of PASID and address
- *
- * This should be called when a retry page fault interrupt is
- * received. If this is a new page fault, it will be added to a hash
- * table. The return value indicates whether this is a new fault, or
- * a fault that was already known and is already being handled.
- *
- * If there are too many pending page faults, this will fail. Retry
- * interrupts should be ignored in this case until there is enough
- * free space.
- *
- * Returns 0 if the fault was added, 1 if the fault was already known,
- * -ENOSPC if there are too many pending faults.
- */
-int amdgpu_ih_add_fault(struct amdgpu_device *adev, u64 key)
-{
-   unsigned long flags;
-   int r = -ENOSPC;
-
-   if (WARN_ON_ONCE(!adev->irq.ih.faults))
-   /* Should be allocated in _ih_sw_init on GPUs that
-* support retry faults and require retry filtering.
-*/
-   return r;
-
-   spin_lock_irqsave(&adev->irq.ih.faults->lock, flags);
-
-   /* Only let the hash table fill up to 50% for best performance */
-   if (adev->irq.ih.faults->count >= (1 << (AMDGPU_PAGEFAULT_HASH_BITS-1)))
-   goto unlock_out;
-
-   r = chash_table_copy_in(&adev->irq.ih.faults->hash, key, NULL);
-   if (!r)
-   adev->irq.ih.faults->count++;
-
-   /* chash_table_copy_in should never fail unless we're losing count */
-   WARN_ON_ONCE(r < 0);
-
-unlock_out:
-   spin_unlock_irqrestore(&adev->irq.ih.faults->lock, flags);
-   return r;
-}
-
-/**
- * amdgpu_ih_clear_fault - Remove a page fault record
- *
- * @adev: amdgpu device pointer
- * @key: 64-bit encoding of PASID and address
- *
- * This should be called when a page fault has been handled. Any
- * future interrupt with this key will be processed as a new
- * page fault.
- */
-void amdgpu_ih_clear_fault(struct amdgpu_device *adev, u64 key)
-{
-   unsigned long flags;
-   int r;
-
-   if (!adev->irq.ih.faults)
-   return;
-
-   spin_lock_irqsave(&adev->irq.ih.faults->lock, flags);
-
-   r = chash_table_remove(&adev->irq.ih.faults->hash, key, NULL);
-   if (!WARN_ON_ONCE(r < 0)) {
-   adev->irq.ih.faults->count--;
-   WARN_ON_ONCE(adev->irq.ih.faults->count < 0);
-   }
-
-   spin_unlock_irqrestore(&adev->irq.ih.faults->lock, flags);
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
index a23e1c0..f411ffb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
@@ -32,13 +32,6 @@ struct amdgpu_device;
  #define AMDGPU_IH_CLIENTID_LEGACY 0
  #define AMDGPU_IH_CLIENTID_MAX SOC15_IH_CLIENTID_MAX
  
-#define AMDGPU_PAGEFAULT_HASH_BITS 8

-struct amdgpu_retryfault_hashtable {
-   DECLARE_CHASH_TABLE(hash, AMDGPU_PAGEFAULT_HASH_BITS, 8, 0);
-   spinlock_t  lock;
-   int count;
-};
-
  /*
   * R6xx+ IH ring
   */
@@ -57,7 +50,6 @@ struct amdgpu_ih_ring {
booluse_doorbell;
booluse_bus_addr;
dma_addr_t  rb_dma_addr; /* only used when use_bus_addr = 
true */
-   struct amdgpu_retryfault_hashtable *faults;
  };
  
  #define AMDGPU_IH_SRC_DATA_MAX_SIZE_DW 4

@@ -95,7 +87,5 @@ int amdgpu_ih_ring_init(struct amdgpu_device *adev, unsigned 
ring_size,
bool use_bus_addr);
  void amdgpu_ih_ring_fini(struct amdgpu_device *adev);
  int amdgpu_ih_process(struct amdgpu_device *adev);
-int amdgpu_ih_add_fault(struct amdgpu_device *adev, u64 key);
-void amdgpu_ih_clear_fault(struct amdgpu_device *adev, u64 key);
  
  #endif

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 1d7e3c1..8b220e9 100644
--- a/drivers/gpu/drm/amd/amdgp

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

7 schrieb Felix Kuehling:

Hi Christian,

I'm not sure I get your point here.

As I understand it, the amdgpu_vm structure represents the user
mode VM
context. It has the pointers to the root page directory and the
rest of
the page table hierarchy. If there is no amdgpu_vm, there is no user
mode context that cares about the page tables.

If we leave the page table pointers in the amdgpu_vm, then handling
faults after the VM is destroyed is pointless. We can't find the page
tables and we can't update them, so there is nothing we can do in
response to VM faults.

So I'm guessing that you want to move the page table pointers into a
different structure that exists half-independently of the VM. It
would
be created when the VM is created (that's where we currently allocate
the PASID) but can be destroyed slightly later.

But why do you want to update page tables when there is no more user
mode context that cares about them? Is this just to allow pending
work
to complete after the user mode context is gone? To prevent hangs?

Regards,
     Felix

On 2018-09-10 07:20 AM, Christian König wrote:

Am I right that the handling of page fault need a valid VM?

No, exactly that view is incorrect.

The VM is meant to be a memory management structure of page
tables and
is completely pointless fault processing because it represent the
future state of the page tables and not the current one.

What we need for fault processing is a new structure build around
PASIDs which is feed by the with addresses when page tables are
moved
around.

Alternatively I hope that we can use the SDMA to walk the page
tables
and update the required entries by just using the address.

Regards,
Christian.

Am 07.09.2018 um 16:55 schrieb Zeng, Oak:

Hi Christian,


What is the value of delay the destroy of hash to after vm is
destroyed? Since vm is destroyed, you basically don’t have enough
information to paging in the correct page to gpuvm. Am I right that
the handling of page fault need a valid VM? For example, you
need the
VM to get the corresponding physical address of the faulty page.


After vm is destroyed, the retry interrupt can be directly
discard as
you can’t find vm through pasid. You can think this is also one
kind
of prescreen.


So I am stand for the point that, there is no need to delay the
destroy of hash to after vm is destroyed. Prescreening hash can be
destroyed at the time of vm_fini.


Thanks,

Oak


*From:*Christian König 
*Sent:* Friday, September 07, 2018 4:39 AM
*To:* Zeng, Oak ; Oak Zeng
;
amd-gfx@lists.freedesktop.org
*Cc:* Zeng, Oak 
*Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to
amdgpu vm


Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a
suggestion but rather a must have.

The VM structures must be destroyed while the processing is still
ongoing, or otherwise we would not have a clean OOM handling.

The IDR for PASID lockup can be put into amdgpu_ids.c, you can just
replace the IDA already used there with an IDR.

Since the PASID is already freed up delayed we should have the
grace
period for interrupt processing included. If that still isn't
sufficient we can still add some delayed work for this.

Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:

   Hi Christian,

   In this implementation, fault hash is made per vm, not per
pasid
   as suggested, based on below considerations:

     * Delay the destroy of hash introduces more effort like
how to
   set the proper grace period after which no retry
interrupt
   will be generated. We want to avoid those complication
if we
   can.
     * The  problem of the per vm implementation is that it
is hard
   to delay the destroy of fault hash, because when vm is
   destroyed, prescreen function won't be able to
retrieve the
   fault hash. But in this case, the prescreen function can
   either let the interrupt go through (to gmc) or ignore
it.
   From this perspective, it is not very necessary to
delay the
   destroy of hash table.
     * On the other hand, since ASICs after vega10 have the
HW CAM
   feature. So the SW IV prescreen is only useful for
vega10.
   For all the HW implemented CAM, we can consider the
delayed
   CAM acknowledgment.
     * Making it per pasid need to introduce another idr to
   correlate pasid and hash table - where to put the idr?
You
   will have to make it a global variable which is not very
   desirable.

   The main purpose of this patch is to solve the inter-process
lock
   issue (when hash table is full), while still keep codes
simple.

   Also with this patch, the faults kfifo is not necessary any
more.
   See patch 2.

   Regards,

   Oak


   On 09/06/2018 11:28 PM, Oak Zeng wrote:

   In stead of share one fault hash table per device,
make it

   per vm. This can av

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Felix Kuehling]

 that
>>>> instead of trying to keep the VM alive as long as possible.
>>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>> Am 08.09.2018 um 02:27 schrieb Felix Kuehling:
>>>>> Hi Christian,
>>>>>
>>>>> I'm not sure I get your point here.
>>>>>
>>>>> As I understand it, the amdgpu_vm structure represents the user
>>>>> mode VM
>>>>> context. It has the pointers to the root page directory and the
>>>>> rest of
>>>>> the page table hierarchy. If there is no amdgpu_vm, there is no user
>>>>> mode context that cares about the page tables.
>>>>>
>>>>> If we leave the page table pointers in the amdgpu_vm, then handling
>>>>> faults after the VM is destroyed is pointless. We can't find the page
>>>>> tables and we can't update them, so there is nothing we can do in
>>>>> response to VM faults.
>>>>>
>>>>> So I'm guessing that you want to move the page table pointers into a
>>>>> different structure that exists half-independently of the VM. It
>>>>> would
>>>>> be created when the VM is created (that's where we currently allocate
>>>>> the PASID) but can be destroyed slightly later.
>>>>>
>>>>> But why do you want to update page tables when there is no more user
>>>>> mode context that cares about them? Is this just to allow pending
>>>>> work
>>>>> to complete after the user mode context is gone? To prevent hangs?
>>>>>
>>>>> Regards,
>>>>>     Felix
>>>>>
>>>>> On 2018-09-10 07:20 AM, Christian König wrote:
>>>>>>> Am I right that the handling of page fault need a valid VM?
>>>>>> No, exactly that view is incorrect.
>>>>>>
>>>>>> The VM is meant to be a memory management structure of page
>>>>>> tables and
>>>>>> is completely pointless fault processing because it represent the
>>>>>> future state of the page tables and not the current one.
>>>>>>
>>>>>> What we need for fault processing is a new structure build around
>>>>>> PASIDs which is feed by the with addresses when page tables are
>>>>>> moved
>>>>>> around.
>>>>>>
>>>>>> Alternatively I hope that we can use the SDMA to walk the page
>>>>>> tables
>>>>>> and update the required entries by just using the address.
>>>>>>
>>>>>> Regards,
>>>>>> Christian.
>>>>>>
>>>>>> Am 07.09.2018 um 16:55 schrieb Zeng, Oak:
>>>>>>> Hi Christian,
>>>>>>>
>>>>>>>
>>>>>>> What is the value of delay the destroy of hash to after vm is
>>>>>>> destroyed? Since vm is destroyed, you basically don’t have enough
>>>>>>> information to paging in the correct page to gpuvm. Am I right that
>>>>>>> the handling of page fault need a valid VM? For example, you
>>>>>>> need the
>>>>>>> VM to get the corresponding physical address of the faulty page.
>>>>>>>
>>>>>>>
>>>>>>> After vm is destroyed, the retry interrupt can be directly
>>>>>>> discard as
>>>>>>> you can’t find vm through pasid. You can think this is also one
>>>>>>> kind
>>>>>>> of prescreen.
>>>>>>>
>>>>>>>
>>>>>>> So I am stand for the point that, there is no need to delay the
>>>>>>> destroy of hash to after vm is destroyed. Prescreening hash can be
>>>>>>> destroyed at the time of vm_fini.
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Oak
>>>>>>>
>>>>>>>
>>>>>>> *From:*Christian König 
>>>>>>> *Sent:* Friday, September 07, 2018 4:39 AM
>>>>>>> *To:* Zeng, Oak ; Oak Zeng
>>>>>>> ;
>>>>>>> amd-gfx@lists.freedesktop.org
>>>>>>> *Cc:* Zeng, Oak 
>>>>>>> *Subject:* Re: [PATCH 1/2] drm/amd

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

Am 11.09.2018 um 17:02 schrieb Zeng, Oak:

Exactly that is what won't work. See we can't mark the PDE invalid because we 
still have some engines which can't deal with retry faults.

By engines do you mean UTCL2 client? If yes, I am not aware of that. If any 
UTCL2 client doesn't support translation retry, driver will need to make sure 
all the current PDE/PTE entries are valid. In other word, it should be setup 
before it is used by any job and can't be swapped out during memory pressure. 
How can it work otherwise?


Yes, exactly. What could maybe work is to use two kinds of page tables.

E.g. we use classic pipelined operation for the high area of the address 
space and page faulting operation for the low area.


I've prototyped that once, but that would still require quite some work 
on the MM side to actually support this kind of operation.


Otherwise as far as I can see the best we can do on GFX9 is to set leave 
node PTEs as valid/invalid as appropriate and fill them on demand when 
the time comes.


Regards,
Christian.



Thanks,
Oak

-Original Message-
From: Christian König 
Sent: Tuesday, September 11, 2018 10:23 AM
To: Zeng, Oak ; Koenig, Christian ; Kuehling, Felix 
; Oak Zeng ; amd-gfx@lists.freedesktop.org; Yang, 
Philip 
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm


[Oak]: Step 5, We also mark the corresponding entry of parent page table of the 
evicted page table to invalid.

Exactly that is what won't work. See we can't mark the PDE invalid because we 
still have some engines which can't deal with retry faults.


[Oak] How do you block it?

Just waiting for all execution to finish.

Regards,
Christian.

Am 11.09.2018 um 16:09 schrieb Zeng, Oak:

Hi Christian,

I am not sure I understand exactly your thought but see 2 comments
inline

Thanks,
Oak

-Original Message-
From: Christian König 
Sent: Tuesday, September 11, 2018 3:19 AM
To: Kuehling, Felix ; Koenig, Christian
; Zeng, Oak ; Oak Zeng
; amd-gfx@lists.freedesktop.org; Yang, Philip

Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu
vm

Hi Felix,

let me try to explain the problem on an example:

1. We have a running job which needs recoverable page faults for accessing the 
process address space.
2. We run into memory pressure on VRAM and start to evict things.
3. A page tables of the running job is picked up for eviction.
4. We schedule a copy command to move the content of the page table to system 
memory.
5. The new system memory location of the page table is noted in its BO.
6. We get a fault from the job and swap in the page from the process address 
space.
7. Now we need to enter the new page address into the page table ->
*BAM*

The problem is now that we don't know the address of the page table because the 
current location was replaced with the future location in step #5.
[Oak]: Step 5, We also mark the corresponding entry of parent page table of the 
evicted page table to invalid. This invalid bit will cause the utcl2 walker to 
report a page fault. Depending on implementation, for the evicted page table, 
its' amdgpu_vm_pt.amdgpu_vm_bo_base will point to a new location in system 
memory (amdgpu_vm_pt itself is in system memory). In the page fault handler, we 
allocate a *new* physical page in vram (through ttm), swap in the page content 
from system memory (using sdma) to this newly allocated page, modify parent 
page table's corresponding entry to point to this *new allocated* page and set 
valid bit to 1.

If all the swap-in, swap-out work is done by sdma, we don't need to worry about 
the case that swap-in happens earlier than swap-out - gpu scheduler will take 
care the sequence.

If ttm can't turn around for the new page allocation, it can optionally trigger 
things like OOM. This should be something that need to be considered at ttm 
physical memory management layer.



We could now argue that we could update the page tables on the fly for the 
evicted page and never wait for the current job to finish, but this won't work 
because not all engines can handle that.

I will circumvent this problem for now by blocking the eviction before step #5.
[Oak] How do you block it? Pin the memory? I agree that swapping out page table 
should be the last resort during a memory pressure handling.

The issue with that is that this pipelining is responsible for nearly 20% of 
the fps in some testcases.

I hope that it won't be that bad when I limit disabling the pipelining to only 
page tables, but it is certainly possible that we will get pushback on this.

If that happens we probably need to add some flags to limit this workaround 
even more to only the root PD and all the PDs/PTs which are involved in 
recoverable faults.

Regards,
Christian.

Am 10.09.2018 um 21:10 schrieb Felix Kuehling:

I'm not sure why you need to distinguish current and future state
when dealing with page f

RE: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Zeng, Oak]

>Exactly that is what won't work. See we can't mark the PDE invalid because we 
>still have some engines which can't deal with retry faults.

By engines do you mean UTCL2 client? If yes, I am not aware of that. If any 
UTCL2 client doesn't support translation retry, driver will need to make sure 
all the current PDE/PTE entries are valid. In other word, it should be setup 
before it is used by any job and can't be swapped out during memory pressure. 
How can it work otherwise?

Thanks,
Oak

-Original Message-
From: Christian König  
Sent: Tuesday, September 11, 2018 10:23 AM
To: Zeng, Oak ; Koenig, Christian ; 
Kuehling, Felix ; Oak Zeng ; 
amd-gfx@lists.freedesktop.org; Yang, Philip 
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

> [Oak]: Step 5, We also mark the corresponding entry of parent page table of 
> the evicted page table to invalid.
Exactly that is what won't work. See we can't mark the PDE invalid because we 
still have some engines which can't deal with retry faults.

> [Oak] How do you block it?
Just waiting for all execution to finish.

Regards,
Christian.

Am 11.09.2018 um 16:09 schrieb Zeng, Oak:
> Hi Christian,
>
> I am not sure I understand exactly your thought but see 2 comments 
> inline
>
> Thanks,
> Oak
>
> -Original Message-
> From: Christian König 
> Sent: Tuesday, September 11, 2018 3:19 AM
> To: Kuehling, Felix ; Koenig, Christian 
> ; Zeng, Oak ; Oak Zeng 
> ; amd-gfx@lists.freedesktop.org; Yang, Philip 
> 
> Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu 
> vm
>
> Hi Felix,
>
> let me try to explain the problem on an example:
>
> 1. We have a running job which needs recoverable page faults for accessing 
> the process address space.
> 2. We run into memory pressure on VRAM and start to evict things.
> 3. A page tables of the running job is picked up for eviction.
> 4. We schedule a copy command to move the content of the page table to system 
> memory.
> 5. The new system memory location of the page table is noted in its BO.
> 6. We get a fault from the job and swap in the page from the process address 
> space.
> 7. Now we need to enter the new page address into the page table -> 
> *BAM*
>
> The problem is now that we don't know the address of the page table because 
> the current location was replaced with the future location in step #5.
> [Oak]: Step 5, We also mark the corresponding entry of parent page table of 
> the evicted page table to invalid. This invalid bit will cause the utcl2 
> walker to report a page fault. Depending on implementation, for the evicted 
> page table, its' amdgpu_vm_pt.amdgpu_vm_bo_base will point to a new location 
> in system memory (amdgpu_vm_pt itself is in system memory). In the page fault 
> handler, we allocate a *new* physical page in vram (through ttm), swap in the 
> page content from system memory (using sdma) to this newly allocated page, 
> modify parent page table's corresponding entry to point to this *new 
> allocated* page and set valid bit to 1.
>
> If all the swap-in, swap-out work is done by sdma, we don't need to worry 
> about the case that swap-in happens earlier than swap-out - gpu scheduler 
> will take care the sequence.
>
> If ttm can't turn around for the new page allocation, it can optionally 
> trigger things like OOM. This should be something that need to be considered 
> at ttm physical memory management layer.
>
>
>
> We could now argue that we could update the page tables on the fly for the 
> evicted page and never wait for the current job to finish, but this won't 
> work because not all engines can handle that.
>
> I will circumvent this problem for now by blocking the eviction before step 
> #5.
> [Oak] How do you block it? Pin the memory? I agree that swapping out page 
> table should be the last resort during a memory pressure handling.
>
> The issue with that is that this pipelining is responsible for nearly 20% of 
> the fps in some testcases.
>
> I hope that it won't be that bad when I limit disabling the pipelining to 
> only page tables, but it is certainly possible that we will get pushback on 
> this.
>
> If that happens we probably need to add some flags to limit this workaround 
> even more to only the root PD and all the PDs/PTs which are involved in 
> recoverable faults.
>
> Regards,
> Christian.
>
> Am 10.09.2018 um 21:10 schrieb Felix Kuehling:
>> I'm not sure why you need to distinguish current and future state 
>> when dealing with page faults. When you get a page fault, you know 
>> that the GPU is trying to access memory right now, in the present. So 
>> you're 

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

[Oak]: Step 5, We also mark the corresponding entry of parent page table of the 
evicted page table to invalid.
Exactly that is what won't work. See we can't mark the PDE invalid 
because we still have some engines which can't deal with retry faults.



[Oak] How do you block it?

Just waiting for all execution to finish.

Regards,
Christian.

Am 11.09.2018 um 16:09 schrieb Zeng, Oak:

Hi Christian,

I am not sure I understand exactly your thought but see 2 comments inline

Thanks,
Oak

-Original Message-
From: Christian König 
Sent: Tuesday, September 11, 2018 3:19 AM
To: Kuehling, Felix ; Koenig, Christian ; Zeng, 
Oak ; Oak Zeng ; amd-gfx@lists.freedesktop.org; Yang, 
Philip 
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Hi Felix,

let me try to explain the problem on an example:

1. We have a running job which needs recoverable page faults for accessing the 
process address space.
2. We run into memory pressure on VRAM and start to evict things.
3. A page tables of the running job is picked up for eviction.
4. We schedule a copy command to move the content of the page table to system 
memory.
5. The new system memory location of the page table is noted in its BO.
6. We get a fault from the job and swap in the page from the process address 
space.
7. Now we need to enter the new page address into the page table -> *BAM*

The problem is now that we don't know the address of the page table because the 
current location was replaced with the future location in step #5.
[Oak]: Step 5, We also mark the corresponding entry of parent page table of the 
evicted page table to invalid. This invalid bit will cause the utcl2 walker to 
report a page fault. Depending on implementation, for the evicted page table, 
its' amdgpu_vm_pt.amdgpu_vm_bo_base will point to a new location in system 
memory (amdgpu_vm_pt itself is in system memory). In the page fault handler, we 
allocate a *new* physical page in vram (through ttm), swap in the page content 
from system memory (using sdma) to this newly allocated page, modify parent 
page table's corresponding entry to point to this *new allocated* page and set 
valid bit to 1.

If all the swap-in, swap-out work is done by sdma, we don't need to worry about 
the case that swap-in happens earlier than swap-out - gpu scheduler will take 
care the sequence.

If ttm can't turn around for the new page allocation, it can optionally trigger 
things like OOM. This should be something that need to be considered at ttm 
physical memory management layer.



We could now argue that we could update the page tables on the fly for the 
evicted page and never wait for the current job to finish, but this won't work 
because not all engines can handle that.

I will circumvent this problem for now by blocking the eviction before step #5.
[Oak] How do you block it? Pin the memory? I agree that swapping out page table 
should be the last resort during a memory pressure handling.

The issue with that is that this pipelining is responsible for nearly 20% of 
the fps in some testcases.

I hope that it won't be that bad when I limit disabling the pipelining to only 
page tables, but it is certainly possible that we will get pushback on this.

If that happens we probably need to add some flags to limit this workaround 
even more to only the root PD and all the PDs/PTs which are involved in 
recoverable faults.

Regards,
Christian.

Am 10.09.2018 um 21:10 schrieb Felix Kuehling:

I'm not sure why you need to distinguish current and future state when
dealing with page faults. When you get a page fault, you know that the
GPU is trying to access memory right now, in the present. So you're
always working with the current state. When the CPU page table
changes, you get an MMU notifier that allows you to invalidate the
corresponding GPU PTEs. If you have a valid GPU PTE, it always
represents the current states and is in sync with the CPU page table.
If the GPU page table is ever outdated, it should have an invalid entry in that 
place.

If SDMA is used to update the GPU PTEs, there is a delay. The MMU
notifier is synchronous, so it shouldn't be a problem. You just wait
for the SDMA job to complete before returning. When updating PTEs with
new valid addresses, it's asynchronous. But the GPU will continue
retrying on the invalid entry until SDMA finishes. So it's also
implicitly synchronized on the GPU side.

Regards,
    Felix


On 2018-09-10 05:42 AM, Christian König wrote:

Hi Felix & Oak,

over the weekend I had the idea that we could just use the shadow BOs
to have the current state in a page fault. They are GTT BOs and CPU
accessible anyway.

Regards,
Christian.

Am 08.09.2018 um 09:34 schrieb Christian König:

Hi Felix,


But why do you want to update page tables when there is no more
user mode context that cares about them? Is this just to allow
pending work to complete after the user m

RE: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Zeng, Oak]

Hi Christian,

I am not sure I understand exactly your thought but see 2 comments inline

Thanks,
Oak

-Original Message-
From: Christian König  
Sent: Tuesday, September 11, 2018 3:19 AM
To: Kuehling, Felix ; Koenig, Christian 
; Zeng, Oak ; Oak Zeng 
; amd-gfx@lists.freedesktop.org; Yang, Philip 

Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Hi Felix,

let me try to explain the problem on an example:

1. We have a running job which needs recoverable page faults for accessing the 
process address space.
2. We run into memory pressure on VRAM and start to evict things.
3. A page tables of the running job is picked up for eviction.
4. We schedule a copy command to move the content of the page table to system 
memory.
5. The new system memory location of the page table is noted in its BO.
6. We get a fault from the job and swap in the page from the process address 
space.
7. Now we need to enter the new page address into the page table -> *BAM*

The problem is now that we don't know the address of the page table because the 
current location was replaced with the future location in step #5.
[Oak]: Step 5, We also mark the corresponding entry of parent page table of the 
evicted page table to invalid. This invalid bit will cause the utcl2 walker to 
report a page fault. Depending on implementation, for the evicted page table, 
its' amdgpu_vm_pt.amdgpu_vm_bo_base will point to a new location in system 
memory (amdgpu_vm_pt itself is in system memory). In the page fault handler, we 
allocate a *new* physical page in vram (through ttm), swap in the page content 
from system memory (using sdma) to this newly allocated page, modify parent 
page table's corresponding entry to point to this *new allocated* page and set 
valid bit to 1.

If all the swap-in, swap-out work is done by sdma, we don't need to worry about 
the case that swap-in happens earlier than swap-out - gpu scheduler will take 
care the sequence.

If ttm can't turn around for the new page allocation, it can optionally trigger 
things like OOM. This should be something that need to be considered at ttm 
physical memory management layer.



We could now argue that we could update the page tables on the fly for the 
evicted page and never wait for the current job to finish, but this won't work 
because not all engines can handle that.

I will circumvent this problem for now by blocking the eviction before step #5. 
[Oak] How do you block it? Pin the memory? I agree that swapping out page table 
should be the last resort during a memory pressure handling. 

The issue with that is that this pipelining is responsible for nearly 20% of 
the fps in some testcases.

I hope that it won't be that bad when I limit disabling the pipelining to only 
page tables, but it is certainly possible that we will get pushback on this.

If that happens we probably need to add some flags to limit this workaround 
even more to only the root PD and all the PDs/PTs which are involved in 
recoverable faults.

Regards,
Christian.

Am 10.09.2018 um 21:10 schrieb Felix Kuehling:
> I'm not sure why you need to distinguish current and future state when 
> dealing with page faults. When you get a page fault, you know that the 
> GPU is trying to access memory right now, in the present. So you're 
> always working with the current state. When the CPU page table 
> changes, you get an MMU notifier that allows you to invalidate the 
> corresponding GPU PTEs. If you have a valid GPU PTE, it always 
> represents the current states and is in sync with the CPU page table. 
> If the GPU page table is ever outdated, it should have an invalid entry in 
> that place.
>
> If SDMA is used to update the GPU PTEs, there is a delay. The MMU 
> notifier is synchronous, so it shouldn't be a problem. You just wait 
> for the SDMA job to complete before returning. When updating PTEs with 
> new valid addresses, it's asynchronous. But the GPU will continue 
> retrying on the invalid entry until SDMA finishes. So it's also 
> implicitly synchronized on the GPU side.
>
> Regards,
>    Felix
>
>
> On 2018-09-10 05:42 AM, Christian König wrote:
>> Hi Felix & Oak,
>>
>> over the weekend I had the idea that we could just use the shadow BOs 
>> to have the current state in a page fault. They are GTT BOs and CPU 
>> accessible anyway.
>>
>> Regards,
>> Christian.
>>
>> Am 08.09.2018 um 09:34 schrieb Christian König:
>>> Hi Felix,
>>>
>>>> But why do you want to update page tables when there is no more 
>>>> user mode context that cares about them? Is this just to allow 
>>>> pending work to complete after the user mode context is gone? To prevent 
>>>> hangs?
>>> The problem I'm see is that we still don&#

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

e.

What we need for fault processing is a new structure build around
PASIDs which is feed by the with addresses when page tables are moved
around.

Alternatively I hope that we can use the SDMA to walk the page tables
and update the required entries by just using the address.

Regards,
Christian.

Am 07.09.2018 um 16:55 schrieb Zeng, Oak:

Hi Christian,


What is the value of delay the destroy of hash to after vm is
destroyed? Since vm is destroyed, you basically don’t have enough
information to paging in the correct page to gpuvm. Am I right that
the handling of page fault need a valid VM? For example, you need the
VM to get the corresponding physical address of the faulty page.


After vm is destroyed, the retry interrupt can be directly discard as
you can’t find vm through pasid. You can think this is also one kind
of prescreen.


So I am stand for the point that, there is no need to delay the
destroy of hash to after vm is destroyed. Prescreening hash can be
destroyed at the time of vm_fini.


Thanks,

Oak


*From:*Christian König 
*Sent:* Friday, September 07, 2018 4:39 AM
*To:* Zeng, Oak ; Oak Zeng ;
amd-gfx@lists.freedesktop.org
*Cc:* Zeng, Oak 
*Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to
amdgpu vm


Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a
suggestion but rather a must have.

The VM structures must be destroyed while the processing is still
ongoing, or otherwise we would not have a clean OOM handling.

The IDR for PASID lockup can be put into amdgpu_ids.c, you can just
replace the IDA already used there with an IDR.

Since the PASID is already freed up delayed we should have the grace
period for interrupt processing included. If that still isn't
sufficient we can still add some delayed work for this.

Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:

  Hi Christian,

  In this implementation, fault hash is made per vm, not per pasid
  as suggested, based on below considerations:

    * Delay the destroy of hash introduces more effort like how to
  set the proper grace period after which no retry interrupt
  will be generated. We want to avoid those complication if we
  can.
    * The  problem of the per vm implementation is that it is hard
  to delay the destroy of fault hash, because when vm is
  destroyed, prescreen function won't be able to retrieve the
  fault hash. But in this case, the prescreen function can
  either let the interrupt go through (to gmc) or ignore it.
  From this perspective, it is not very necessary to delay the
  destroy of hash table.
    * On the other hand, since ASICs after vega10 have the HW CAM
  feature. So the SW IV prescreen is only useful for vega10.
  For all the HW implemented CAM, we can consider the delayed
  CAM acknowledgment.
    * Making it per pasid need to introduce another idr to
  correlate pasid and hash table - where to put the idr? You
  will have to make it a global variable which is not very
  desirable.

  The main purpose of this patch is to solve the inter-process
lock
  issue (when hash table is full), while still keep codes simple.

  Also with this patch, the faults kfifo is not necessary any
more.
  See patch 2.

  Regards,

  Oak


  On 09/06/2018 11:28 PM, Oak Zeng wrote:

  In stead of share one fault hash table per device, make it

  per vm. This can avoid inter-process lock issue when fault

  hash table is full.


  Change-Id: I5d1281b7c41eddc8e26113e010516557588d3708

  Signed-off-by: Oak Zeng 
<mailto:oak.z...@amd.com>

  Suggested-by: Christian Konig 
<mailto:christian.koe...@amd.com>

  Suggested-by: Felix Kuehling 
<mailto:felix.kuehl...@amd.com>

  ---

   drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c |  75


   drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h |  10 

   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 102
-

   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  12 

   drivers/gpu/drm/amd/amdgpu/vega10_ih.c |  38 +---

   5 files changed, 127 insertions(+), 110 deletions(-)


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

  index 06373d4..4ed8621 100644

  --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c

  +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c

  @@ -197,78 +197,3 @@ int amdgpu_ih_process(struct
amdgpu_device *adev)

     return IRQ_HANDLED;

   }


  -/**

  - * amdgpu_ih_add_fault - Add a page fault record

  - *

  - * @adev: amdgpu device pointer

  - * @key: 64-bit encoding of PASID and address

  - *

  - * This should be called wh

RE: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Zeng, Oak]

Hi Christian,

Ok, then can I get a reviewed-by for this change?

I will drop patch 2 for now, as Philip said offline that he will still need to 
use that kfifo. I will follow up with Philip anyway.

I will re-work on the translation retry patches, after this one.

Probably also follow up the idea of calling kfd interrupt handling from IP 
block interrupt handler.

Also see one more comments inline.

Thanks,
Oak

From: Koenig, Christian
Sent: Saturday, September 08, 2018 3:16 AM
To: Zeng, Oak ; Oak Zeng ; 
amd-gfx@lists.freedesktop.org; Yang, Philip 
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Hi Oak,


>In other words when you request the address of a PT you get the address where 
>memory management has moved it, not the address where the hardware is 
>processing the fault from.

Do you mean the address in the PT is what vm has mapped and the faulty address 
need to be mapped in the PT?
No, the memory management is pipelined to avoid stalls during eviction.

This means that the state we manage is always the future state, e.g. when you 
walk the page tables in the VM structure you see the state after all the 
running operations completed.

In other words when a page table is pipelined for eviction you see the evicted 
state and not the current executing one.

But what we need for page fault handling is the current state and not the 
future state.

[Oak]: We might think the page fault handling differently. In my mind, there is 
not much need to differentiate b/t current and future page table. When pages 
are moved, the corresponding page table entries should be marked as invalid. 
During the page fault handling, driver should allocate new physical pages (and 
swap in pages content.  Only necessary for evicted pages.) and update page 
table accordingly. In this process, there is only one page table state, the one 
reflect the current mapping.



The amdgpu_vm and amdgpu_vm_pt data structure are invented for the purpose of 
management of page table BO. Why we need invent extra structure?
We will need something like a double entry accounting for the page tables where 
we both keep the future as well as the current state.


Think about the normal case of the page fault handling when the process and vm 
are still alive. In the normal case, the amdgpu_vm structure can meet exactly 
purpose of page table update.
No, the problem is not if the VM is still alive or dead but rather that in the 
case of an eviction you wouldn't be able to handle page faults any more.


The said extra data structure must look very similar to the amdgpu_vm/vm_pt 
structure. So the best way is to reuse the existing vm structure, either in 
normal case or in process termination case.
Completely agree that we will probably need the same structure as the VM 
hierarchy offers, just with another set of information.


Is it possible to delay the destroy of vm during process termination?
Yeah, thought about that as well. The problem with that is the OOM killer and 
that we are still not able to reliable kill running command submissions.

Ok you convinced me that we should probably work on that instead.

E.g. when a process has bound its address space to a VM and exits we need to 
find a way to kill all still executing jobs. We should let the UMD handle that 
case gracefully when they really need this.

Thanks,
Christian.

Am 07.09.2018 um 23:52 schrieb Zeng, Oak:
Hi Christian,

See comments inline

Thanks,
Oak

From: Koenig, Christian
Sent: Monday, September 10, 2018 7:44 AM
To: Zeng, Oak <mailto:oak.z...@amd.com>; Oak Zeng 
<mailto:zengshan...@gmail.com>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; Yang, 
Philip <mailto:philip.y...@amd.com>
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

>The VM doesn't know that information either.

Yes, VM doesn’t know the information. More specifically I meant we need VM data 
structure to update PTs during page fault handling. For example, we walk the 4 
level page table (the first level is pointed by vm->root) to figure out the 
entries need to be filled, allocate page table entry Bos if necessary, allocate 
physical page for the faulty address, setup 4 level page table for the faulty 
virtual address to pointing to the allocated physical page.

>In other words when you request the address of a PT you get the address where 
>memory management has moved it, not the address where the hardware is 
>processing the fault from.

Do you mean the address in the PT is what vm has mapped and the faulty address 
need to be mapped in the PT?


I see only a few possible solutions for that:
>1. We use an extra structure in the kernel driver which holds the current 
>address of the PTs and is feed by memory management when buffers move around.
The amdgpu_vm and amdgpu_vm_pt data structure are invented for the purpose of 
management of page table BO. Why we need invent extra st

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Felix Kuehling]

;>>> the handling of page fault need a valid VM? For example, you need the
>>>>> VM to get the corresponding physical address of the faulty page.
>>>>>
>>>>>
>>>>> After vm is destroyed, the retry interrupt can be directly discard as
>>>>> you can’t find vm through pasid. You can think this is also one kind
>>>>> of prescreen.
>>>>>
>>>>>
>>>>> So I am stand for the point that, there is no need to delay the
>>>>> destroy of hash to after vm is destroyed. Prescreening hash can be
>>>>> destroyed at the time of vm_fini.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Oak
>>>>>
>>>>>
>>>>> *From:*Christian König 
>>>>> *Sent:* Friday, September 07, 2018 4:39 AM
>>>>> *To:* Zeng, Oak ; Oak Zeng ;
>>>>> amd-gfx@lists.freedesktop.org
>>>>> *Cc:* Zeng, Oak 
>>>>> *Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to
>>>>> amdgpu vm
>>>>>
>>>>>
>>>>> Hi Oak,
>>>>>
>>>>> yeah, but this is still a NAK. Making the hash per PASID was not a
>>>>> suggestion but rather a must have.
>>>>>
>>>>> The VM structures must be destroyed while the processing is still
>>>>> ongoing, or otherwise we would not have a clean OOM handling.
>>>>>
>>>>> The IDR for PASID lockup can be put into amdgpu_ids.c, you can just
>>>>> replace the IDA already used there with an IDR.
>>>>>
>>>>> Since the PASID is already freed up delayed we should have the grace
>>>>> period for interrupt processing included. If that still isn't
>>>>> sufficient we can still add some delayed work for this.
>>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>> Am 07.09.2018 um 06:16 schrieb ozeng:
>>>>>
>>>>>  Hi Christian,
>>>>>
>>>>>  In this implementation, fault hash is made per vm, not per pasid
>>>>>  as suggested, based on below considerations:
>>>>>
>>>>>    * Delay the destroy of hash introduces more effort like how to
>>>>>  set the proper grace period after which no retry interrupt
>>>>>  will be generated. We want to avoid those complication if we
>>>>>  can.
>>>>>    * The  problem of the per vm implementation is that it is hard
>>>>>  to delay the destroy of fault hash, because when vm is
>>>>>  destroyed, prescreen function won't be able to retrieve the
>>>>>  fault hash. But in this case, the prescreen function can
>>>>>  either let the interrupt go through (to gmc) or ignore it.
>>>>>  From this perspective, it is not very necessary to delay the
>>>>>  destroy of hash table.
>>>>>    * On the other hand, since ASICs after vega10 have the HW CAM
>>>>>  feature. So the SW IV prescreen is only useful for vega10.
>>>>>  For all the HW implemented CAM, we can consider the delayed
>>>>>  CAM acknowledgment.
>>>>>    * Making it per pasid need to introduce another idr to
>>>>>  correlate pasid and hash table - where to put the idr? You
>>>>>  will have to make it a global variable which is not very
>>>>>  desirable.
>>>>>
>>>>>  The main purpose of this patch is to solve the inter-process
>>>>> lock
>>>>>  issue (when hash table is full), while still keep codes simple.
>>>>>
>>>>>  Also with this patch, the faults kfifo is not necessary any
>>>>> more.
>>>>>  See patch 2.
>>>>>
>>>>>  Regards,
>>>>>
>>>>>  Oak
>>>>>
>>>>>
>>>>>  On 09/06/2018 11:28 PM, Oak Zeng wrote:
>>>>>
>>>>>  In stead of share one fault hash table per device, make it
>>>>>
>>>>>  per vm. This can avoid inter-process lock issue when fault
>>>>>
>>>>>  hash table is full.
>>>>>
>>>>>
>>>

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

Hi Felix & Oak,

over the weekend I had the idea that we could just use the shadow BOs to 
have the current state in a page fault. They are GTT BOs and CPU 
accessible anyway.


Regards,
Christian.

Am 08.09.2018 um 09:34 schrieb Christian König:

Hi Felix,


But why do you want to update page tables when there is no more user
mode context that cares about them? Is this just to allow pending work
to complete after the user mode context is gone? To prevent hangs?


The problem I'm see is that we still don't have a reliable way of 
killing a command submission while making sure that no more faults of 
it are in the flight.


E.g. the HWS has a function to kill a running job on the hardware, but 
that only works for compute and there is no way of telling when that 
operation has finished.


But Oak has already convinced me that we should probably work on that 
instead of trying to keep the VM alive as long as possible.


Regards,
Christian.

Am 08.09.2018 um 02:27 schrieb Felix Kuehling:

Hi Christian,

I'm not sure I get your point here.

As I understand it, the amdgpu_vm structure represents the user mode VM
context. It has the pointers to the root page directory and the rest of
the page table hierarchy. If there is no amdgpu_vm, there is no user
mode context that cares about the page tables.

If we leave the page table pointers in the amdgpu_vm, then handling
faults after the VM is destroyed is pointless. We can't find the page
tables and we can't update them, so there is nothing we can do in
response to VM faults.

So I'm guessing that you want to move the page table pointers into a
different structure that exists half-independently of the VM. It would
be created when the VM is created (that's where we currently allocate
the PASID) but can be destroyed slightly later.

But why do you want to update page tables when there is no more user
mode context that cares about them? Is this just to allow pending work
to complete after the user mode context is gone? To prevent hangs?

Regards,
   Felix

On 2018-09-10 07:20 AM, Christian König wrote:

Am I right that the handling of page fault need a valid VM?

No, exactly that view is incorrect.

The VM is meant to be a memory management structure of page tables and
is completely pointless fault processing because it represent the
future state of the page tables and not the current one.

What we need for fault processing is a new structure build around
PASIDs which is feed by the with addresses when page tables are moved
around.

Alternatively I hope that we can use the SDMA to walk the page tables
and update the required entries by just using the address.

Regards,
Christian.

Am 07.09.2018 um 16:55 schrieb Zeng, Oak:

Hi Christian,


What is the value of delay the destroy of hash to after vm is
destroyed? Since vm is destroyed, you basically don’t have enough
information to paging in the correct page to gpuvm. Am I right that
the handling of page fault need a valid VM? For example, you need the
VM to get the corresponding physical address of the faulty page.


After vm is destroyed, the retry interrupt can be directly discard as
you can’t find vm through pasid. You can think this is also one kind
of prescreen.


So I am stand for the point that, there is no need to delay the
destroy of hash to after vm is destroyed. Prescreening hash can be
destroyed at the time of vm_fini.


Thanks,

Oak


*From:*Christian König 
*Sent:* Friday, September 07, 2018 4:39 AM
*To:* Zeng, Oak ; Oak Zeng ;
amd-gfx@lists.freedesktop.org
*Cc:* Zeng, Oak 
*Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to
amdgpu vm


Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a
suggestion but rather a must have.

The VM structures must be destroyed while the processing is still
ongoing, or otherwise we would not have a clean OOM handling.

The IDR for PASID lockup can be put into amdgpu_ids.c, you can just
replace the IDA already used there with an IDR.

Since the PASID is already freed up delayed we should have the grace
period for interrupt processing included. If that still isn't
sufficient we can still add some delayed work for this.

Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:

 Hi Christian,

 In this implementation, fault hash is made per vm, not per pasid
 as suggested, based on below considerations:

   * Delay the destroy of hash introduces more effort like how to
 set the proper grace period after which no retry interrupt
 will be generated. We want to avoid those complication if we
 can.
   * The  problem of the per vm implementation is that it is hard
 to delay the destroy of fault hash, because when vm is
 destroyed, prescreen function won't be able to retrieve the
 fault hash. But in this case, the prescreen function can
 either let the interrupt go through (to gmc) or ignore it.
 From this p

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

Hi Felix,


But why do you want to update page tables when there is no more user
mode context that cares about them? Is this just to allow pending work
to complete after the user mode context is gone? To prevent hangs?


The problem I'm see is that we still don't have a reliable way of 
killing a command submission while making sure that no more faults of it 
are in the flight.


E.g. the HWS has a function to kill a running job on the hardware, but 
that only works for compute and there is no way of telling when that 
operation has finished.


But Oak has already convinced me that we should probably work on that 
instead of trying to keep the VM alive as long as possible.


Regards,
Christian.

Am 08.09.2018 um 02:27 schrieb Felix Kuehling:

Hi Christian,

I'm not sure I get your point here.

As I understand it, the amdgpu_vm structure represents the user mode VM
context. It has the pointers to the root page directory and the rest of
the page table hierarchy. If there is no amdgpu_vm, there is no user
mode context that cares about the page tables.

If we leave the page table pointers in the amdgpu_vm, then handling
faults after the VM is destroyed is pointless. We can't find the page
tables and we can't update them, so there is nothing we can do in
response to VM faults.

So I'm guessing that you want to move the page table pointers into a
different structure that exists half-independently of the VM. It would
be created when the VM is created (that's where we currently allocate
the PASID) but can be destroyed slightly later.

But why do you want to update page tables when there is no more user
mode context that cares about them? Is this just to allow pending work
to complete after the user mode context is gone? To prevent hangs?

Regards,
   Felix

On 2018-09-10 07:20 AM, Christian König wrote:

Am I right that the handling of page fault need a valid VM?

No, exactly that view is incorrect.

The VM is meant to be a memory management structure of page tables and
is completely pointless fault processing because it represent the
future state of the page tables and not the current one.

What we need for fault processing is a new structure build around
PASIDs which is feed by the with addresses when page tables are moved
around.

Alternatively I hope that we can use the SDMA to walk the page tables
and update the required entries by just using the address.

Regards,
Christian.

Am 07.09.2018 um 16:55 schrieb Zeng, Oak:

Hi Christian,

  


What is the value of delay the destroy of hash to after vm is
destroyed? Since vm is destroyed, you basically don’t have enough
information to paging in the correct page to gpuvm. Am I right that
the handling of page fault need a valid VM? For example, you need the
VM to get the corresponding physical address of the faulty page.

  


After vm is destroyed, the retry interrupt can be directly discard as
you can’t find vm through pasid. You can think this is also one kind
of prescreen.

  


So I am stand for the point that, there is no need to delay the
destroy of hash to after vm is destroyed. Prescreening hash can be
destroyed at the time of vm_fini.

  


Thanks,

Oak

  


*From:*Christian König 
*Sent:* Friday, September 07, 2018 4:39 AM
*To:* Zeng, Oak ; Oak Zeng ;
amd-gfx@lists.freedesktop.org
*Cc:* Zeng, Oak 
*Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to
amdgpu vm

  


Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a
suggestion but rather a must have.

The VM structures must be destroyed while the processing is still
ongoing, or otherwise we would not have a clean OOM handling.

The IDR for PASID lockup can be put into amdgpu_ids.c, you can just
replace the IDA already used there with an IDR.

Since the PASID is already freed up delayed we should have the grace
period for interrupt processing included. If that still isn't
sufficient we can still add some delayed work for this.

Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:

 Hi Christian,

 In this implementation, fault hash is made per vm, not per pasid
 as suggested, based on below considerations:

   * Delay the destroy of hash introduces more effort like how to
 set the proper grace period after which no retry interrupt
 will be generated. We want to avoid those complication if we
 can.
   * The  problem of the per vm implementation is that it is hard
 to delay the destroy of fault hash, because when vm is
 destroyed, prescreen function won't be able to retrieve the
 fault hash. But in this case, the prescreen function can
 either let the interrupt go through (to gmc) or ignore it.
 From this perspective, it is not very necessary to delay the
 destroy of hash table.
   * On the other hand, since ASICs after vega10 have the HW CAM
 feature. So the SW IV prescreen is only useful for vega10.
 For al

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

Hi Oak,

>In other words when you request the address of a PT you get the 
address where memory management has moved it, not the address where 
the hardware is processing the fault from.


Do you mean the address in the PT is what vm has mapped and the faulty 
address need to be mapped in the PT?



No, the memory management is pipelined to avoid stalls during eviction.

This means that the state we manage is always the future state, e.g. 
when you walk the page tables in the VM structure you see the state 
after all the running operations completed.


In other words when a page table is pipelined for eviction you see the 
evicted state and not the current executing one.


But what we need for page fault handling is the current state and not 
the future state.


The amdgpu_vm and amdgpu_vm_pt data structure are invented for the 
purpose of management of page table BO. Why we need invent extra 
structure?
We will need something like a double entry accounting for the page 
tables where we both keep the future as well as the current state.


Think about the normal case of the page fault handling when the 
process and vm are still alive. In the normal case, the amdgpu_vm 
structure can meet exactly purpose of page table update.
No, the problem is not if the VM is still alive or dead but rather that 
in the case of an eviction you wouldn't be able to handle page faults 
any more.


The said extra data structure must look very similar to the 
amdgpu_vm/vm_pt structure. So the best way is to reuse the existing vm 
structure, either in normal case or in process termination case.
Completely agree that we will probably need the same structure as the VM 
hierarchy offers, just with another set of information.



Is it possible to delay the destroy of vm during process termination?
Yeah, thought about that as well. The problem with that is the OOM 
killer and that we are still not able to reliable kill running command 
submissions.


Ok you convinced me that we should probably work on that instead.

E.g. when a process has bound its address space to a VM and exits we 
need to find a way to kill all still executing jobs. We should let the 
UMD handle that case gracefully when they really need this.


Thanks,
Christian.

Am 07.09.2018 um 23:52 schrieb Zeng, Oak:


Hi Christian,

See comments inline

Thanks,

Oak

*From:*Koenig, Christian
*Sent:* Monday, September 10, 2018 7:44 AM
*To:* Zeng, Oak ; Oak Zeng ; 
amd-gfx@lists.freedesktop.org; Yang, Philip 

*Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

>The VM doesn't know that information either.

Yes, VM doesn’t know the information. More specifically I meant we 
need VM data structure to update PTs during page fault handling. For 
example, we walk the 4 level page table (the first level is pointed by 
vm->root) to figure out the entries need to be filled, allocate page 
table entry Bos if necessary, allocate physical page for the faulty 
address, setup 4 level page table for the faulty virtual address to 
pointing to the allocated physical page.


>In other words when you request the address of a PT you get the 
address where memory management has moved it, not the address where 
the hardware is processing the fault from.


Do you mean the address in the PT is what vm has mapped and the faulty 
address need to be mapped in the PT?




I see only a few possible solutions for that:
>1. We use an extra structure in the kernel driver which holds the 
current address of the PTs and is feed by memory management when 
buffers move around.


The amdgpu_vm and amdgpu_vm_pt data structure are invented for the 
purpose of management of page table BO. Why we need invent extra 
structure? Think about the normal case of the page fault handling when 
the process and vm are still alive. In the normal case, the amdgpu_vm 
structure can meet exactly purpose of page table update.


The said extra data structure must look very similar to the 
amdgpu_vm/vm_pt structure. So the best way is to reuse the existing vm 
structure, either in normal case or in process termination case. Is it 
possible to delay the destroy of vm during process termination?



>2. We change the SDMA firmware to do the walk for us and update the 
PTEs based on the information in the page directory.


As the page table BO need to be freed later. You still need to manage 
them in the driver. SDMA FW can walk and update but it need 
information from driver side. Driver still need a similar struct like 
amdgpu_vm.



>3. We use the UTCL walker to get us to the correct address which is 
then updated with the SDMA.
I don’t quite understand your point here. What do you mean by “correct 
address”? Do you mean the physical address to be filled to the page 
table? If this is your meaning, how UTCL2 knows this information – the 
physical address has to be allocated/validated through driver.



Regards,
Christian.

Am 07.09.2018 um 17:30 schrieb Zeng, Oak:

Wi

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Felix Kuehling]

Hi Christian,

I'm not sure I get your point here.

As I understand it, the amdgpu_vm structure represents the user mode VM
context. It has the pointers to the root page directory and the rest of
the page table hierarchy. If there is no amdgpu_vm, there is no user
mode context that cares about the page tables.

If we leave the page table pointers in the amdgpu_vm, then handling
faults after the VM is destroyed is pointless. We can't find the page
tables and we can't update them, so there is nothing we can do in
response to VM faults.

So I'm guessing that you want to move the page table pointers into a
different structure that exists half-independently of the VM. It would
be created when the VM is created (that's where we currently allocate
the PASID) but can be destroyed slightly later.

But why do you want to update page tables when there is no more user
mode context that cares about them? Is this just to allow pending work
to complete after the user mode context is gone? To prevent hangs?

Regards,
  Felix

On 2018-09-10 07:20 AM, Christian König wrote:
>> Am I right that the handling of page fault need a valid VM? 
> No, exactly that view is incorrect.
>
> The VM is meant to be a memory management structure of page tables and
> is completely pointless fault processing because it represent the
> future state of the page tables and not the current one.
>
> What we need for fault processing is a new structure build around
> PASIDs which is feed by the with addresses when page tables are moved
> around.
>
> Alternatively I hope that we can use the SDMA to walk the page tables
> and update the required entries by just using the address.
>
> Regards,
> Christian.
>
> Am 07.09.2018 um 16:55 schrieb Zeng, Oak:
>>
>> Hi Christian,
>>
>>  
>>
>> What is the value of delay the destroy of hash to after vm is
>> destroyed? Since vm is destroyed, you basically don’t have enough
>> information to paging in the correct page to gpuvm. Am I right that
>> the handling of page fault need a valid VM? For example, you need the
>> VM to get the corresponding physical address of the faulty page.
>>
>>  
>>
>> After vm is destroyed, the retry interrupt can be directly discard as
>> you can’t find vm through pasid. You can think this is also one kind
>> of prescreen.
>>
>>  
>>
>> So I am stand for the point that, there is no need to delay the
>> destroy of hash to after vm is destroyed. Prescreening hash can be
>> destroyed at the time of vm_fini.
>>
>>  
>>
>> Thanks,
>>
>> Oak
>>
>>  
>>
>> *From:*Christian König 
>> *Sent:* Friday, September 07, 2018 4:39 AM
>> *To:* Zeng, Oak ; Oak Zeng ;
>> amd-gfx@lists.freedesktop.org
>> *Cc:* Zeng, Oak 
>> *Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to
>> amdgpu vm
>>
>>  
>>
>> Hi Oak,
>>
>> yeah, but this is still a NAK. Making the hash per PASID was not a
>> suggestion but rather a must have.
>>
>> The VM structures must be destroyed while the processing is still
>> ongoing, or otherwise we would not have a clean OOM handling.
>>
>> The IDR for PASID lockup can be put into amdgpu_ids.c, you can just
>> replace the IDA already used there with an IDR.
>>
>> Since the PASID is already freed up delayed we should have the grace
>> period for interrupt processing included. If that still isn't
>> sufficient we can still add some delayed work for this.
>>
>> Regards,
>> Christian.
>>
>> Am 07.09.2018 um 06:16 schrieb ozeng:
>>
>> Hi Christian,
>>
>> In this implementation, fault hash is made per vm, not per pasid
>> as suggested, based on below considerations:
>>
>>   * Delay the destroy of hash introduces more effort like how to
>> set the proper grace period after which no retry interrupt
>> will be generated. We want to avoid those complication if we
>> can.
>>   * The  problem of the per vm implementation is that it is hard
>> to delay the destroy of fault hash, because when vm is
>> destroyed, prescreen function won't be able to retrieve the
>> fault hash. But in this case, the prescreen function can
>> either let the interrupt go through (to gmc) or ignore it.
>> From this perspective, it is not very necessary to delay the
>> destroy of hash table.
>>   * On the other hand, since ASICs after vega10 have the HW CAM
>> feature. So the SW IV prescreen is only useful for vega10.
>> For

RE: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Zeng, Oak]

Hi Christian,

See comments inline

Thanks,
Oak

From: Koenig, Christian
Sent: Monday, September 10, 2018 7:44 AM
To: Zeng, Oak ; Oak Zeng ; 
amd-gfx@lists.freedesktop.org; Yang, Philip 
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

>The VM doesn't know that information either.

Yes, VM doesn’t know the information. More specifically I meant we need VM data 
structure to update PTs during page fault handling. For example, we walk the 4 
level page table (the first level is pointed by vm->root) to figure out the 
entries need to be filled, allocate page table entry Bos if necessary, allocate 
physical page for the faulty address, setup 4 level page table for the faulty 
virtual address to pointing to the allocated physical page.

>In other words when you request the address of a PT you get the address where 
>memory management has moved it, not the address where the hardware is 
>processing the fault from.

Do you mean the address in the PT is what vm has mapped and the faulty address 
need to be mapped in the PT?


I see only a few possible solutions for that:
>1. We use an extra structure in the kernel driver which holds the current 
>address of the PTs and is feed by memory management when buffers move around.
The amdgpu_vm and amdgpu_vm_pt data structure are invented for the purpose of 
management of page table BO. Why we need invent extra structure? Think about 
the normal case of the page fault handling when the process and vm are still 
alive. In the normal case, the amdgpu_vm structure can meet exactly purpose of 
page table update.

The said extra data structure must look very similar to the amdgpu_vm/vm_pt 
structure. So the best way is to reuse the existing vm structure, either in 
normal case or in process termination case. Is it possible to delay the destroy 
of vm during process termination?

>2. We change the SDMA firmware to do the walk for us and update the PTEs based 
>on the information in the page directory.
As the page table BO need to be freed later. You still need to manage them in 
the driver. SDMA FW can walk and update but it need information from driver 
side. Driver still need a similar struct like amdgpu_vm.

>3. We use the UTCL walker to get us to the correct address which is then 
>updated with the SDMA.
I don’t quite understand your point here. What do you mean by “correct 
address”? Do you mean the physical address to be filled to the page table? If 
this is your meaning, how UTCL2 knows this information – the physical address 
has to be allocated/validated through driver.


Regards,
Christian.

Am 07.09.2018 um 17:30 schrieb Zeng, Oak:
Without a VM, how can you get the physical address of the faulty virtual 
address? Where this information should be hold?

Thanks,
Oak

From: Koenig, Christian
Sent: Monday, September 10, 2018 7:20 AM
To: Zeng, Oak <mailto:oak.z...@amd.com>; Oak Zeng 
<mailto:zengshan...@gmail.com>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; Yang, 
Philip <mailto:philip.y...@amd.com>
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Am I right that the handling of page fault need a valid VM?
No, exactly that view is incorrect.

The VM is meant to be a memory management structure of page tables and is 
completely pointless fault processing because it represent the future state of 
the page tables and not the current one.

What we need for fault processing is a new structure build around PASIDs which 
is feed by the with addresses when page tables are moved around.

Alternatively I hope that we can use the SDMA to walk the page tables and 
update the required entries by just using the address.

Regards,
Christian.

Am 07.09.2018 um 16:55 schrieb Zeng, Oak:
Hi Christian,

What is the value of delay the destroy of hash to after vm is destroyed? Since 
vm is destroyed, you basically don’t have enough information to paging in the 
correct page to gpuvm. Am I right that the handling of page fault need a valid 
VM? For example, you need the VM to get the corresponding physical address of 
the faulty page.

After vm is destroyed, the retry interrupt can be directly discard as you can’t 
find vm through pasid. You can think this is also one kind of prescreen.

So I am stand for the point that, there is no need to delay the destroy of hash 
to after vm is destroyed. Prescreening hash can be destroyed at the time of 
vm_fini.

Thanks,
Oak

From: Christian König 
<mailto:ckoenig.leichtzumer...@gmail.com>
Sent: Friday, September 07, 2018 4:39 AM
To: Zeng, Oak <mailto:oak.z...@amd.com>; Oak Zeng 
<mailto:zengshan...@gmail.com>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Zeng, Oak <mailto:oak.z...@amd.com>
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a suggestion 
but rather

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

The VM doesn't know that information either.

In other words when you request the address of a PT you get the address 
where memory management has moved it, not the address where the hardware 
is processing the fault from.


I see only a few possible solutions for that:
1. We use an extra structure in the kernel driver which holds the 
current address of the PTs and is feed by memory management when buffers 
move around.
2. We change the SDMA firmware to do the walk for us and update the PTEs 
based on the information in the page directory.
3. We use the UTCL walker to get us to the correct address which is then 
updated with the SDMA.


Regards,
Christian.

Am 07.09.2018 um 17:30 schrieb Zeng, Oak:


Without a VM, how can you get the physical address of the faulty 
virtual address? Where this information should be hold?


Thanks,

Oak

*From:*Koenig, Christian
*Sent:* Monday, September 10, 2018 7:20 AM
*To:* Zeng, Oak ; Oak Zeng ; 
amd-gfx@lists.freedesktop.org; Yang, Philip 

*Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Am I right that the handling of page fault need a valid VM?

No, exactly that view is incorrect.

The VM is meant to be a memory management structure of page tables and 
is completely pointless fault processing because it represent the 
future state of the page tables and not the current one.


What we need for fault processing is a new structure build around 
PASIDs which is feed by the with addresses when page tables are moved 
around.


Alternatively I hope that we can use the SDMA to walk the page tables 
and update the required entries by just using the address.


Regards,
Christian.

Am 07.09.2018 um 16:55 schrieb Zeng, Oak:

Hi Christian,

What is the value of delay the destroy of hash to after vm is
destroyed? Since vm is destroyed, you basically don’t have enough
information to paging in the correct page to gpuvm. Am I right
that the handling of page fault need a valid VM? For example, you
need the VM to get the corresponding physical address of the
faulty page.

After vm is destroyed, the retry interrupt can be directly discard
as you can’t find vm through pasid. You can think this is also one
kind of prescreen.

So I am stand for the point that, there is no need to delay the
destroy of hash to after vm is destroyed. Prescreening hash can be
destroyed at the time of vm_fini.

Thanks,

Oak

*From:*Christian König 
<mailto:ckoenig.leichtzumer...@gmail.com>
*Sent:* Friday, September 07, 2018 4:39 AM
*To:* Zeng, Oak  <mailto:oak.z...@amd.com>; Oak
Zeng  <mailto:zengshan...@gmail.com>;
amd-gfx@lists.freedesktop.org <mailto:amd-gfx@lists.freedesktop.org>
*Cc:* Zeng, Oak  <mailto:oak.z...@amd.com>
*Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to
amdgpu vm

Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a
suggestion but rather a must have.

The VM structures must be destroyed while the processing is still
ongoing, or otherwise we would not have a clean OOM handling.

The IDR for PASID lockup can be put into amdgpu_ids.c, you can
just replace the IDA already used there with an IDR.

Since the PASID is already freed up delayed we should have the
grace period for interrupt processing included. If that still
isn't sufficient we can still add some delayed work for this.

Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:

Hi Christian,

In this implementation, fault hash is made per vm, not per
pasid as suggested, based on below considerations:

  * Delay the destroy of hash introduces more effort like how
to set the proper grace period after which no retry
interrupt will be generated. We want to avoid those
complication if we can.
  * The  problem of the per vm implementation is that it is
hard to delay the destroy of fault hash, because when vm
is destroyed, prescreen function won't be able to retrieve
the fault hash. But in this case, the prescreen function
can either let the interrupt go through (to gmc) or ignore
it. From this perspective, it is not very necessary to
delay the destroy of hash table.
  * On the other hand, since ASICs after vega10 have the HW
CAM feature. So the SW IV prescreen is only useful for
vega10. For all the HW implemented CAM, we can consider
the delayed CAM acknowledgment.
  * Making it per pasid need to introduce another idr to
correlate pasid and hash table - where to put the idr? You
will have to make it a global variable which is not very
desirable.

The main purpose of this patch is to solve the inter-process
lock issue (whe

RE: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Zeng, Oak]

Without a VM, how can you get the physical address of the faulty virtual 
address? Where this information should be hold?

Thanks,
Oak

From: Koenig, Christian
Sent: Monday, September 10, 2018 7:20 AM
To: Zeng, Oak ; Oak Zeng ; 
amd-gfx@lists.freedesktop.org; Yang, Philip 
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Am I right that the handling of page fault need a valid VM?
No, exactly that view is incorrect.

The VM is meant to be a memory management structure of page tables and is 
completely pointless fault processing because it represent the future state of 
the page tables and not the current one.

What we need for fault processing is a new structure build around PASIDs which 
is feed by the with addresses when page tables are moved around.

Alternatively I hope that we can use the SDMA to walk the page tables and 
update the required entries by just using the address.

Regards,
Christian.

Am 07.09.2018 um 16:55 schrieb Zeng, Oak:
Hi Christian,

What is the value of delay the destroy of hash to after vm is destroyed? Since 
vm is destroyed, you basically don’t have enough information to paging in the 
correct page to gpuvm. Am I right that the handling of page fault need a valid 
VM? For example, you need the VM to get the corresponding physical address of 
the faulty page.

After vm is destroyed, the retry interrupt can be directly discard as you can’t 
find vm through pasid. You can think this is also one kind of prescreen.

So I am stand for the point that, there is no need to delay the destroy of hash 
to after vm is destroyed. Prescreening hash can be destroyed at the time of 
vm_fini.

Thanks,
Oak

From: Christian König 
<mailto:ckoenig.leichtzumer...@gmail.com>
Sent: Friday, September 07, 2018 4:39 AM
To: Zeng, Oak <mailto:oak.z...@amd.com>; Oak Zeng 
<mailto:zengshan...@gmail.com>; 
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Cc: Zeng, Oak <mailto:oak.z...@amd.com>
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a suggestion 
but rather a must have.

The VM structures must be destroyed while the processing is still ongoing, or 
otherwise we would not have a clean OOM handling.

The IDR for PASID lockup can be put into amdgpu_ids.c, you can just replace the 
IDA already used there with an IDR.

Since the PASID is already freed up delayed we should have the grace period for 
interrupt processing included. If that still isn't sufficient we can still add 
some delayed work for this.

Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:

Hi Christian,

In this implementation, fault hash is made per vm, not per pasid as suggested, 
based on below considerations:

  *   Delay the destroy of hash introduces more effort like how to set the 
proper grace period after which no retry interrupt will be generated. We want 
to avoid those complication if we can.
  *   The  problem of the per vm implementation is that it is hard to delay the 
destroy of fault hash, because when vm is destroyed, prescreen function won't 
be able to retrieve the fault hash. But in this case, the prescreen function 
can either let the interrupt go through (to gmc) or ignore it. From this 
perspective, it is not very necessary to delay the destroy of hash table.
  *   On the other hand, since ASICs after vega10 have the HW CAM feature. So 
the SW IV prescreen is only useful for vega10. For all the HW implemented CAM, 
we can consider the delayed CAM acknowledgment.
  *   Making it per pasid need to introduce another idr to correlate pasid and 
hash table - where to put the idr? You will have to make it a global variable 
which is not very desirable.

The main purpose of this patch is to solve the inter-process lock issue (when 
hash table is full), while still keep codes simple.

Also with this patch, the faults kfifo is not necessary any more. See patch 2.

Regards,

Oak

On 09/06/2018 11:28 PM, Oak Zeng wrote:

In stead of share one fault hash table per device, make it

per vm. This can avoid inter-process lock issue when fault

hash table is full.



Change-Id: I5d1281b7c41eddc8e26113e010516557588d3708

Signed-off-by: Oak Zeng <mailto:oak.z...@amd.com>

Suggested-by: Christian Konig 
<mailto:christian.koe...@amd.com>

Suggested-by: Felix Kuehling 
<mailto:felix.kuehl...@amd.com>

---

 drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c |  75 

 drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h |  10 

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 102 -

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  12 

 drivers/gpu/drm/amd/amdgpu/vega10_ih.c |  38 +---

 5 files changed, 127 insertions(+), 110 deletions(-)



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

index 06373d4..4ed8621 100644

--- a/drivers/gpu/drm/amd/amdgpu

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

Am I right that the handling of page fault need a valid VM? 

No, exactly that view is incorrect.

The VM is meant to be a memory management structure of page tables and 
is completely pointless fault processing because it represent the future 
state of the page tables and not the current one.


What we need for fault processing is a new structure build around PASIDs 
which is feed by the with addresses when page tables are moved around.


Alternatively I hope that we can use the SDMA to walk the page tables 
and update the required entries by just using the address.


Regards,
Christian.

Am 07.09.2018 um 16:55 schrieb Zeng, Oak:


Hi Christian,

What is the value of delay the destroy of hash to after vm is 
destroyed? Since vm is destroyed, you basically don’t have enough 
information to paging in the correct page to gpuvm. Am I right that 
the handling of page fault need a valid VM? For example, you need the 
VM to get the corresponding physical address of the faulty page.


After vm is destroyed, the retry interrupt can be directly discard as 
you can’t find vm through pasid. You can think this is also one kind 
of prescreen.


So I am stand for the point that, there is no need to delay the 
destroy of hash to after vm is destroyed. Prescreening hash can be 
destroyed at the time of vm_fini.


Thanks,

Oak

*From:*Christian König 
*Sent:* Friday, September 07, 2018 4:39 AM
*To:* Zeng, Oak ; Oak Zeng ; 
amd-gfx@lists.freedesktop.org

*Cc:* Zeng, Oak 
*Subject:* Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a 
suggestion but rather a must have.


The VM structures must be destroyed while the processing is still 
ongoing, or otherwise we would not have a clean OOM handling.


The IDR for PASID lockup can be put into amdgpu_ids.c, you can just 
replace the IDA already used there with an IDR.


Since the PASID is already freed up delayed we should have the grace 
period for interrupt processing included. If that still isn't 
sufficient we can still add some delayed work for this.


Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:

Hi Christian,

In this implementation, fault hash is made per vm, not per pasid
as suggested, based on below considerations:

  * Delay the destroy of hash introduces more effort like how to
set the proper grace period after which no retry interrupt
will be generated. We want to avoid those complication if we can.
  * The  problem of the per vm implementation is that it is hard
to delay the destroy of fault hash, because when vm is
destroyed, prescreen function won't be able to retrieve the
fault hash. But in this case, the prescreen function can
either let the interrupt go through (to gmc) or ignore it.
From this perspective, it is not very necessary to delay the
destroy of hash table.
  * On the other hand, since ASICs after vega10 have the HW CAM
feature. So the SW IV prescreen is only useful for vega10. For
all the HW implemented CAM, we can consider the delayed CAM
acknowledgment.
  * Making it per pasid need to introduce another idr to correlate
pasid and hash table - where to put the idr? You will have to
make it a global variable which is not very desirable.

The main purpose of this patch is to solve the inter-process lock
issue (when hash table is full), while still keep codes simple.

Also with this patch, the faults kfifo is not necessary any more.
See patch 2.

Regards,

Oak

On 09/06/2018 11:28 PM, Oak Zeng wrote:

In stead of share one fault hash table per device, make it

per vm. This can avoid inter-process lock issue when fault

hash table is full.

Change-Id: I5d1281b7c41eddc8e26113e010516557588d3708

Signed-off-by: Oak Zeng <mailto:oak.z...@amd.com>

Suggested-by: Christian Konig 
<mailto:christian.koe...@amd.com>

Suggested-by: Felix Kuehling 
<mailto:felix.kuehl...@amd.com>

---

  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c |  75 

  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h |  10 

  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 102 
-

  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  12 

  drivers/gpu/drm/amd/amdgpu/vega10_ih.c |  38 +---

  5 files changed, 127 insertions(+), 110 deletions(-)

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

index 06373d4..4ed8621 100644

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c

+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c

@@ -197,78 +197,3 @@ int amdgpu_ih_process(struct amdgpu_device *adev)

    return IRQ_HANDLED;

  }

  


-/**

- * amdg

RE: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Zeng, Oak]

Hi Christian,

What is the value of delay the destroy of hash to after vm is destroyed? Since 
vm is destroyed, you basically don’t have enough information to paging in the 
correct page to gpuvm. Am I right that the handling of page fault need a valid 
VM? For example, you need the VM to get the corresponding physical address of 
the faulty page.

After vm is destroyed, the retry interrupt can be directly discard as you can’t 
find vm through pasid. You can think this is also one kind of prescreen.

So I am stand for the point that, there is no need to delay the destroy of hash 
to after vm is destroyed. Prescreening hash can be destroyed at the time of 
vm_fini.

Thanks,
Oak

From: Christian König 
Sent: Friday, September 07, 2018 4:39 AM
To: Zeng, Oak ; Oak Zeng ; 
amd-gfx@lists.freedesktop.org
Cc: Zeng, Oak 
Subject: Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a suggestion 
but rather a must have.

The VM structures must be destroyed while the processing is still ongoing, or 
otherwise we would not have a clean OOM handling.

The IDR for PASID lockup can be put into amdgpu_ids.c, you can just replace the 
IDA already used there with an IDR.

Since the PASID is already freed up delayed we should have the grace period for 
interrupt processing included. If that still isn't sufficient we can still add 
some delayed work for this.

Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:

Hi Christian,

In this implementation, fault hash is made per vm, not per pasid as suggested, 
based on below considerations:

  *   Delay the destroy of hash introduces more effort like how to set the 
proper grace period after which no retry interrupt will be generated. We want 
to avoid those complication if we can.
  *   The  problem of the per vm implementation is that it is hard to delay the 
destroy of fault hash, because when vm is destroyed, prescreen function won't 
be able to retrieve the fault hash. But in this case, the prescreen function 
can either let the interrupt go through (to gmc) or ignore it. From this 
perspective, it is not very necessary to delay the destroy of hash table.
  *   On the other hand, since ASICs after vega10 have the HW CAM feature. So 
the SW IV prescreen is only useful for vega10. For all the HW implemented CAM, 
we can consider the delayed CAM acknowledgment.
  *   Making it per pasid need to introduce another idr to correlate pasid and 
hash table - where to put the idr? You will have to make it a global variable 
which is not very desirable.

The main purpose of this patch is to solve the inter-process lock issue (when 
hash table is full), while still keep codes simple.

Also with this patch, the faults kfifo is not necessary any more. See patch 2.

Regards,

Oak

On 09/06/2018 11:28 PM, Oak Zeng wrote:

In stead of share one fault hash table per device, make it

per vm. This can avoid inter-process lock issue when fault

hash table is full.



Change-Id: I5d1281b7c41eddc8e26113e010516557588d3708

Signed-off-by: Oak Zeng <mailto:oak.z...@amd.com>

Suggested-by: Christian Konig 
<mailto:christian.koe...@amd.com>

Suggested-by: Felix Kuehling 
<mailto:felix.kuehl...@amd.com>

---

 drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c |  75 

 drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h |  10 

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 102 -

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  12 

 drivers/gpu/drm/amd/amdgpu/vega10_ih.c |  38 +---

 5 files changed, 127 insertions(+), 110 deletions(-)



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

index 06373d4..4ed8621 100644

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c

+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c

@@ -197,78 +197,3 @@ int amdgpu_ih_process(struct amdgpu_device *adev)

   return IRQ_HANDLED;

 }



-/**

- * amdgpu_ih_add_fault - Add a page fault record

- *

- * @adev: amdgpu device pointer

- * @key: 64-bit encoding of PASID and address

- *

- * This should be called when a retry page fault interrupt is

- * received. If this is a new page fault, it will be added to a hash

- * table. The return value indicates whether this is a new fault, or

- * a fault that was already known and is already being handled.

- *

- * If there are too many pending page faults, this will fail. Retry

- * interrupts should be ignored in this case until there is enough

- * free space.

- *

- * Returns 0 if the fault was added, 1 if the fault was already known,

- * -ENOSPC if there are too many pending faults.

- */

-int amdgpu_ih_add_fault(struct amdgpu_device *adev, u64 key)

-{

-  unsigned long flags;

-  int r = -ENOSPC;

-

-  if (WARN_ON_ONCE(!adev->irq.ih.faults))

-  /* Should be allocated in _ih_sw_init on GPUs that

-   * support retry faults and require retry filtering.

-   

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Christian König]

Hi Oak,

yeah, but this is still a NAK. Making the hash per PASID was not a 
suggestion but rather a must have.


The VM structures must be destroyed while the processing is still 
ongoing, or otherwise we would not have a clean OOM handling.


The IDR for PASID lockup can be put into amdgpu_ids.c, you can just 
replace the IDA already used there with an IDR.


Since the PASID is already freed up delayed we should have the grace 
period for interrupt processing included. If that still isn't sufficient 
we can still add some delayed work for this.


Regards,
Christian.

Am 07.09.2018 um 06:16 schrieb ozeng:


Hi Christian,

In this implementation, fault hash is made per vm, not per pasid as 
suggested, based on below considerations:


  * Delay the destroy of hash introduces more effort like how to set
the proper grace period after which no retry interrupt will be
generated. We want to avoid those complication if we can.
  * The  problem of the per vm implementation is that it is hard to
delay the destroy of fault hash, because when vm is destroyed,
prescreen function won't be able to retrieve the fault hash. But
in this case, the prescreen function can either let the interrupt
go through (to gmc) or ignore it. From this perspective, it is not
very necessary to delay the destroy of hash table.
  * On the other hand, since ASICs after vega10 have the HW CAM
feature. So the SW IV prescreen is only useful for vega10. For all
the HW implemented CAM, we can consider the delayed CAM
acknowledgment.
  * Making it per pasid need to introduce another idr to correlate
pasid and hash table - where to put the idr? You will have to make
it a global variable which is not very desirable.

The main purpose of this patch is to solve the inter-process lock 
issue (when hash table is full), while still keep codes simple.


Also with this patch, the faults kfifo is not necessary any more. See 
patch 2.


Regards,

Oak


On 09/06/2018 11:28 PM, Oak Zeng wrote:

In stead of share one fault hash table per device, make it
per vm. This can avoid inter-process lock issue when fault
hash table is full.

Change-Id: I5d1281b7c41eddc8e26113e010516557588d3708
Signed-off-by: Oak Zeng
Suggested-by: Christian Konig
Suggested-by: Felix Kuehling
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c |  75 
  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h |  10 
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 102 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  12 
  drivers/gpu/drm/amd/amdgpu/vega10_ih.c |  38 +---
  5 files changed, 127 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index 06373d4..4ed8621 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -197,78 +197,3 @@ int amdgpu_ih_process(struct amdgpu_device *adev)
return IRQ_HANDLED;
  }
  
-/**

- * amdgpu_ih_add_fault - Add a page fault record
- *
- * @adev: amdgpu device pointer
- * @key: 64-bit encoding of PASID and address
- *
- * This should be called when a retry page fault interrupt is
- * received. If this is a new page fault, it will be added to a hash
- * table. The return value indicates whether this is a new fault, or
- * a fault that was already known and is already being handled.
- *
- * If there are too many pending page faults, this will fail. Retry
- * interrupts should be ignored in this case until there is enough
- * free space.
- *
- * Returns 0 if the fault was added, 1 if the fault was already known,
- * -ENOSPC if there are too many pending faults.
- */
-int amdgpu_ih_add_fault(struct amdgpu_device *adev, u64 key)
-{
-   unsigned long flags;
-   int r = -ENOSPC;
-
-   if (WARN_ON_ONCE(!adev->irq.ih.faults))
-   /* Should be allocated in _ih_sw_init on GPUs that
-* support retry faults and require retry filtering.
-*/
-   return r;
-
-   spin_lock_irqsave(&adev->irq.ih.faults->lock, flags);
-
-   /* Only let the hash table fill up to 50% for best performance */
-   if (adev->irq.ih.faults->count >= (1 << (AMDGPU_PAGEFAULT_HASH_BITS-1)))
-   goto unlock_out;
-
-   r = chash_table_copy_in(&adev->irq.ih.faults->hash, key, NULL);
-   if (!r)
-   adev->irq.ih.faults->count++;
-
-   /* chash_table_copy_in should never fail unless we're losing count */
-   WARN_ON_ONCE(r < 0);
-
-unlock_out:
-   spin_unlock_irqrestore(&adev->irq.ih.faults->lock, flags);
-   return r;
-}
-
-/**
- * amdgpu_ih_clear_fault - Remove a page fault record
- *
- * @adev: amdgpu device pointer
- * @key: 64-bit encoding of PASID and address
- *
- * This should be called when a page fault has been handled. Any
- * future interrupt with this key will be processed as a new
- * page fault.
- */
-void amdgpu_ih_clear_fault(struct amdgpu_device *ad

[PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[Oak Zeng]

In stead of share one fault hash table per device, make it
per vm. This can avoid inter-process lock issue when fault
hash table is full.

Change-Id: I5d1281b7c41eddc8e26113e010516557588d3708
Signed-off-by: Oak Zeng 
Suggested-by: Christian Konig 
Suggested-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c |  75 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h |  10 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 102 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  12 
 drivers/gpu/drm/amd/amdgpu/vega10_ih.c |  38 +---
 5 files changed, 127 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index 06373d4..4ed8621 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -197,78 +197,3 @@ int amdgpu_ih_process(struct amdgpu_device *adev)
return IRQ_HANDLED;
 }
 
-/**
- * amdgpu_ih_add_fault - Add a page fault record
- *
- * @adev: amdgpu device pointer
- * @key: 64-bit encoding of PASID and address
- *
- * This should be called when a retry page fault interrupt is
- * received. If this is a new page fault, it will be added to a hash
- * table. The return value indicates whether this is a new fault, or
- * a fault that was already known and is already being handled.
- *
- * If there are too many pending page faults, this will fail. Retry
- * interrupts should be ignored in this case until there is enough
- * free space.
- *
- * Returns 0 if the fault was added, 1 if the fault was already known,
- * -ENOSPC if there are too many pending faults.
- */
-int amdgpu_ih_add_fault(struct amdgpu_device *adev, u64 key)
-{
-   unsigned long flags;
-   int r = -ENOSPC;
-
-   if (WARN_ON_ONCE(!adev->irq.ih.faults))
-   /* Should be allocated in _ih_sw_init on GPUs that
-* support retry faults and require retry filtering.
-*/
-   return r;
-
-   spin_lock_irqsave(&adev->irq.ih.faults->lock, flags);
-
-   /* Only let the hash table fill up to 50% for best performance */
-   if (adev->irq.ih.faults->count >= (1 << (AMDGPU_PAGEFAULT_HASH_BITS-1)))
-   goto unlock_out;
-
-   r = chash_table_copy_in(&adev->irq.ih.faults->hash, key, NULL);
-   if (!r)
-   adev->irq.ih.faults->count++;
-
-   /* chash_table_copy_in should never fail unless we're losing count */
-   WARN_ON_ONCE(r < 0);
-
-unlock_out:
-   spin_unlock_irqrestore(&adev->irq.ih.faults->lock, flags);
-   return r;
-}
-
-/**
- * amdgpu_ih_clear_fault - Remove a page fault record
- *
- * @adev: amdgpu device pointer
- * @key: 64-bit encoding of PASID and address
- *
- * This should be called when a page fault has been handled. Any
- * future interrupt with this key will be processed as a new
- * page fault.
- */
-void amdgpu_ih_clear_fault(struct amdgpu_device *adev, u64 key)
-{
-   unsigned long flags;
-   int r;
-
-   if (!adev->irq.ih.faults)
-   return;
-
-   spin_lock_irqsave(&adev->irq.ih.faults->lock, flags);
-
-   r = chash_table_remove(&adev->irq.ih.faults->hash, key, NULL);
-   if (!WARN_ON_ONCE(r < 0)) {
-   adev->irq.ih.faults->count--;
-   WARN_ON_ONCE(adev->irq.ih.faults->count < 0);
-   }
-
-   spin_unlock_irqrestore(&adev->irq.ih.faults->lock, flags);
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
index a23e1c0..f411ffb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
@@ -32,13 +32,6 @@ struct amdgpu_device;
 #define AMDGPU_IH_CLIENTID_LEGACY 0
 #define AMDGPU_IH_CLIENTID_MAX SOC15_IH_CLIENTID_MAX
 
-#define AMDGPU_PAGEFAULT_HASH_BITS 8
-struct amdgpu_retryfault_hashtable {
-   DECLARE_CHASH_TABLE(hash, AMDGPU_PAGEFAULT_HASH_BITS, 8, 0);
-   spinlock_t  lock;
-   int count;
-};
-
 /*
  * R6xx+ IH ring
  */
@@ -57,7 +50,6 @@ struct amdgpu_ih_ring {
booluse_doorbell;
booluse_bus_addr;
dma_addr_t  rb_dma_addr; /* only used when use_bus_addr = 
true */
-   struct amdgpu_retryfault_hashtable *faults;
 };
 
 #define AMDGPU_IH_SRC_DATA_MAX_SIZE_DW 4
@@ -95,7 +87,5 @@ int amdgpu_ih_ring_init(struct amdgpu_device *adev, unsigned 
ring_size,
bool use_bus_addr);
 void amdgpu_ih_ring_fini(struct amdgpu_device *adev);
 int amdgpu_ih_process(struct amdgpu_device *adev);
-int amdgpu_ih_add_fault(struct amdgpu_device *adev, u64 key);
-void amdgpu_ih_clear_fault(struct amdgpu_device *adev, u64 key);
 
 #endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 1d7e3c1..8b220e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2692,6 +2692,22 @@ void amdgpu_vm_adjus

Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm

[ozeng]

Hi Christian,

In this implementation, fault hash is made per vm, not per pasid as 
suggested, based on below considerations:


 * Delay the destroy of hash introduces more effort like how to set the
   proper grace period after which no retry interrupt will be
   generated. We want to avoid those complication if we can.
 * The  problem of the per vm implementation is that it is hard to
   delay the destroy of fault hash, because when vm is destroyed,
   prescreen function won't be able to retrieve the fault hash. But in
   this case, the prescreen function can either let the interrupt go
   through (to gmc) or ignore it. From this perspective, it is not very
   necessary to delay the destroy of hash table.
 * On the other hand, since ASICs after vega10 have the HW CAM feature.
   So the SW IV prescreen is only useful for vega10. For all the HW
   implemented CAM, we can consider the delayed CAM acknowledgment.
 * Making it per pasid need to introduce another idr to correlate pasid
   and hash table - where to put the idr? You will have to make it a
   global variable which is not very desirable.

The main purpose of this patch is to solve the inter-process lock issue 
(when hash table is full), while still keep codes simple.


Also with this patch, the faults kfifo is not necessary any more. See 
patch 2.


Regards,

Oak


On 09/06/2018 11:28 PM, Oak Zeng wrote:

In stead of share one fault hash table per device, make it
per vm. This can avoid inter-process lock issue when fault
hash table is full.

Change-Id: I5d1281b7c41eddc8e26113e010516557588d3708
Signed-off-by: Oak Zeng 
Suggested-by: Christian Konig 
Suggested-by: Felix Kuehling 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c |  75 
  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h |  10 
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 102 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  12 
  drivers/gpu/drm/amd/amdgpu/vega10_ih.c |  38 +---
  5 files changed, 127 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index 06373d4..4ed8621 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
@@ -197,78 +197,3 @@ int amdgpu_ih_process(struct amdgpu_device *adev)
return IRQ_HANDLED;
  }
  
-/**

- * amdgpu_ih_add_fault - Add a page fault record
- *
- * @adev: amdgpu device pointer
- * @key: 64-bit encoding of PASID and address
- *
- * This should be called when a retry page fault interrupt is
- * received. If this is a new page fault, it will be added to a hash
- * table. The return value indicates whether this is a new fault, or
- * a fault that was already known and is already being handled.
- *
- * If there are too many pending page faults, this will fail. Retry
- * interrupts should be ignored in this case until there is enough
- * free space.
- *
- * Returns 0 if the fault was added, 1 if the fault was already known,
- * -ENOSPC if there are too many pending faults.
- */
-int amdgpu_ih_add_fault(struct amdgpu_device *adev, u64 key)
-{
-   unsigned long flags;
-   int r = -ENOSPC;
-
-   if (WARN_ON_ONCE(!adev->irq.ih.faults))
-   /* Should be allocated in _ih_sw_init on GPUs that
-* support retry faults and require retry filtering.
-*/
-   return r;
-
-   spin_lock_irqsave(&adev->irq.ih.faults->lock, flags);
-
-   /* Only let the hash table fill up to 50% for best performance */
-   if (adev->irq.ih.faults->count >= (1 << (AMDGPU_PAGEFAULT_HASH_BITS-1)))
-   goto unlock_out;
-
-   r = chash_table_copy_in(&adev->irq.ih.faults->hash, key, NULL);
-   if (!r)
-   adev->irq.ih.faults->count++;
-
-   /* chash_table_copy_in should never fail unless we're losing count */
-   WARN_ON_ONCE(r < 0);
-
-unlock_out:
-   spin_unlock_irqrestore(&adev->irq.ih.faults->lock, flags);
-   return r;
-}
-
-/**
- * amdgpu_ih_clear_fault - Remove a page fault record
- *
- * @adev: amdgpu device pointer
- * @key: 64-bit encoding of PASID and address
- *
- * This should be called when a page fault has been handled. Any
- * future interrupt with this key will be processed as a new
- * page fault.
- */
-void amdgpu_ih_clear_fault(struct amdgpu_device *adev, u64 key)
-{
-   unsigned long flags;
-   int r;
-
-   if (!adev->irq.ih.faults)
-   return;
-
-   spin_lock_irqsave(&adev->irq.ih.faults->lock, flags);
-
-   r = chash_table_remove(&adev->irq.ih.faults->hash, key, NULL);
-   if (!WARN_ON_ONCE(r < 0)) {
-   adev->irq.ih.faults->count--;
-   WARN_ON_ONCE(adev->irq.ih.faults->count < 0);
-   }
-
-   spin_unlock_irqrestore(&adev->irq.ih.faults->lock, flags);
-}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
index a23e1c0..f411ffb 100644
--- a/drivers/gpu/drm/amd