Am 14.12.2017 um 08:24 schrieb Thomas Hellstrom:
On 12/13/2017 09:55 PM, Thomas Hellstrom wrote:Hi, Christian,While this has probably already been committed, and looks like a nice cleanup there are two things below I think needs fixing.On 11/15/2017 01:31 PM, Christian König wrote:There is no guarantee that the next entry on the ddelete list stays on the list when we drop the locks. Completely rework this mess by moving processed entries on a temporary list. Signed-off-by: Christian König <christian.koenig@xxxxxxx> ---drivers/gpu/drm/ttm/ttm_bo.c | 77 ++++++++++++++------------------------------1 file changed, 25 insertions(+), 52 deletions(-)diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.cindex 7c1eac4f4b4b..ad0afdd71f21 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c@@ -572,71 +572,47 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,* Traverse the delayed list, and call ttm_bo_cleanup_refs on all * encountered buffers. */ --static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all) +static bool ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all){ struct ttm_bo_global *glob = bdev->glob; - struct ttm_buffer_object *entry = NULL; - int ret = 0; - - spin_lock(&glob->lru_lock); - if (list_empty(&bdev->ddestroy)) - goto out_unlock; + struct list_head removed; + bool empty; - entry = list_first_entry(&bdev->ddestroy, - struct ttm_buffer_object, ddestroy); - kref_get(&entry->list_kref); + INIT_LIST_HEAD(&removed); - for (;;) { - struct ttm_buffer_object *nentry = NULL; - - if (entry->ddestroy.next != &bdev->ddestroy) { - nentry = list_first_entry(&entry->ddestroy, - struct ttm_buffer_object, ddestroy); - kref_get(&nentry->list_kref); - } - - ret = reservation_object_trylock(entry->resv) ? 0 : -EBUSY; - if (remove_all && ret) { - spin_unlock(&glob->lru_lock); - ret = reservation_object_lock(entry->resv, NULL); - spin_lock(&glob->lru_lock); - } + spin_lock(&glob->lru_lock); + while (!list_empty(&bdev->ddestroy)) { + struct ttm_buffer_object *bo; - if (!ret) - ret = ttm_bo_cleanup_refs(entry, false, !remove_all, - true); - else - spin_unlock(&glob->lru_lock);+ bo = list_first_entry(&bdev->ddestroy, struct ttm_buffer_object,+ ddestroy); + kref_get(&bo->list_kref); + list_move_tail(&bo->ddestroy, &removed); + spin_unlock(&glob->lru_lock); - kref_put(&entry->list_kref, ttm_bo_release_list); - entry = nentry; + reservation_object_lock(bo->resv, NULL);Reservation may be a long lived lock, and typically if the object is reserved here, it's being evicted somewhere and there might be a substantial stall, which isn't really acceptable in the global workqueue. Better to move on to the next bo. This function was really intended to be non-blocking, unless remove_all == true. I even think it's safe to keep the spinlock held on tryreserve?
This approach doesn't really work with shared reservation objects and was actually the originally reason why I stumbled over the function being a bit buggy.
The reservation object is a really busy lock because of all the command submission going on. So when you only have a single trylock every few ms it is rather unlikely that you can actually grab it. We ended up with tons of objects on the ddestroy list which couldn't be reaped because of this.
At least amdgpu tries to avoid to wait for any GPU operation while holding the reservation locks, so at least for us that shouldn't be an issue any more. And I'm going to pipeline delayed deletes as well rather soon.
What we could do here is to use a test like "bo->resv == &bo->ttm_resv" and only trylock if it isn't a shared reservation object. How about that?
Regards, Christian.
- if (ret || !entry) - goto out; + spin_lock(&glob->lru_lock); + ttm_bo_cleanup_refs(bo, false, !remove_all, true); + kref_put(&bo->list_kref, ttm_bo_release_list);Calling a release function in atomic context is a bad thing. Nobody knows what locks needs to be taken in the release function and such code is prone to lock inversion and sleep-while-atomic bugs. Not long ago vfree() was even forbidden from atomic context. But here it's easily avoidable.Hmm. It actually looks like ttm_bo_cleanup_refs unlocks the glob->lru_lock just loke ttm_bo_cleanup_refs_and_unlock did, so my latter comment actually isn't correct. Intuitively removing the "unlock" prefix from the function would also mean that the unlocking functionality went away, but that doesn't seem to be the case. Also the commit message "needed for the next patch" isn't very helpful when the next patch is actually commited much later...The first comment about trylocking still holds, though. /Thomas/Thomas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
