Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm
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
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
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
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
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
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
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
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
>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
[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
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
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
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
;>>> 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
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
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
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
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
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
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
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
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
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
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
Re: [PATCH 1/2] drm/amdgpu: Moved fault hash table to amdgpu vm
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