Am 03.07.2018 um 10:12 schrieb Zhang, Jerry (Junwei): > On 07/03/2018 02:58 PM, Christian König wrote: >> Am 03.07.2018 um 03:59 schrieb Zhang, Jerry (Junwei): >>> On 07/02/2018 05:23 PM, Christian König wrote: >>>> [SNIP] >> The reservation_object_reserve_shared() function needs to be called >> before you make submissions to the hardware to make sure that you >> have a free slot after you made the submission. >> >> The problem is now that we always reserve one free slot during >> command submission, but for the page directory reservation object it >> can happen that this free slot is used by VM updates. >> >> So the safest approach is to make sure that we have another free slot >> after the VM updates are done. >> >> Michel's patch nearly did that, because we rarely have only one >> submission in amdgpu_vm_update_directories(). But it isn't 100% correct. > > Thanks to explain that, I think got your meaning that we should > reserve slot for command submission after VM update. > > if so, shall we add reservation_object_reserve_shared() for both of > them, since any of place may run out of slot. > > While the gap from me is I fail to find reserving slot during command > submission, That's done by ttm_eu_reserve_buffers(). > the root bo reservation seems to be used by VM update only(if not > correct me). No, that is not correct. The root BO is also part of the list of BOs for the command submission used by ttm_eu_reserve_buffers() and ttm_eu_fence_buffer_objects(). All VM updates will use the same slot, so we just need one extra reservation_object_reserve_shared() after all the VM updates are done. Regards, Christian. > command submission is likely to use bo's reservation from bo list > rather than root bo reservation. > > BTW, reservation_object_reserve_shared() will extend the max num as 2 > times if it's not enough. > (default value is 4) > > Jerry
