drm/ttm: lru lock atomicity removal

This requires re-use of the seqno, which increases fairness slightly. Instead of spinning with a new seqno every time we keep the current one, but still drop all other reservations we hold. Only when we succeed, we try to get back our other reservations again.

This should increase fairness slightly as well.

Signed-off-by Maarten Lankhorst <[email protected]>

---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

drivers/gpu/drm/ttm/ttm_execbuf_util.c +0 -0

index c7d3236..c02b2b6 100644

drivers/gpu/drm/ttm/ttm_execbuf_util.c +11 -2

        list_for_each_entry(entry, list, head) {
                struct ttm_buffer_object *bo = entry->bo;
 
+               /* already slowpath reserved? */
+               if (entry->reserved)
+                       continue;
+
                ret = ttm_bo_reserve_nolru(bo, true, true, true, val_seq);
                switch (ret) {
                case 0:

@@ -157,9 +161,15 @@ retry:
                        ttm_eu_backoff_reservation_locked(list);
                        spin_unlock(&glob->lru_lock);
                        ttm_eu_list_ref_sub(list);
-                       ret = ttm_bo_wait_unreserved(bo, true);
+                       ret = ttm_bo_reserve_slowpath_nolru(bo, true, val_seq);
                        if (unlikely(ret != 0))
                                return ret;
+                       spin_lock(&glob->lru_lock);
+                       entry->reserved = true;
+                       if (unlikely(atomic_read(&bo->cpu_writers) > 0)) {
+                               ret = -EBUSY;
+                               goto err;
+                       }
                        goto retry;
                default:
                        goto err;
--

1.8.0

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 24 lines · Maarten Lankhorst

This requires re-use of the seqno, which increases fairness slightly. Instead of spinning with a new seqno every time we keep the current one, but still drop all other reservations we hold. Only when we succeed, we try to get back our other reservations again.

This should increase fairness slightly as well.

Signed-off-by Maarten Lankhorst <[email protected]>

---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

drivers/gpu/drm/ttm/ttm_execbuf_util.c +0 -1

index c7d3236..c02b2b6 100644
@@ -129,13 +129,17 @@ int ttm_eu_reserve_buffers(struct list_head *list)
        entry = list_first_entry(list, struct ttm_validate_buffer, head);
        glob = entry->bo->glob;
 
-retry:
        spin_lock(&glob->lru_lock);
        val_seq = entry->bo->bdev->val_seq++;
 

drivers/gpu/drm/ttm/ttm_execbuf_util.c int ttm_eu_reserve_buffers(struct list_head *list) · line 135

Quoted 1 line

drivers/gpu/drm/ttm/ttm_execbuf_util.c +1 -0

+retry:

After more thinking while i was going over patches to send comment i think this one is bad, really bad. So here is bad case i see, we have a list of 2 bo A & B. We succeed reserving A we set seq_valid to true and val_seq to our val_seq. We fail on B, we go slow path and unreserve A. Some other CPU reserve A but before it write either seq_valid or val_seq we wakeup reserve B and retry to reserve A in reserve_nolru we see A as reserved we enter the while loop see seq_valid set and test val_seq against our same old val_seq we got == and return -EDEADLCK which is definitly not what we want to do. If we inc val seq on retry we will never have this case. So what exactly not incrementing it gave us ?

I think the read and write memory barrier i was talking in patch 1 should avoid any such things to happen but i need to sleep on that to make nightmare about all things that can go wrong.

Op 06-12-12 02:36, Jerome Glisse schreef:

Quoted 26 lines

Quoted 24 lines · Maarten Lankhorst

This requires re-use of the seqno, which increases fairness slightly. Instead of spinning with a new seqno every time we keep the current one, but still drop all other reservations we hold. Only when we succeed, we try to get back our other reservations again.

This should increase fairness slightly as well.

Signed-off-by Maarten Lankhorst <[email protected]>

---
 drivers/gpu/drm/ttm/ttm_execbuf_util.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

drivers/gpu/drm/ttm/ttm_execbuf_util.c +0 -1

index c7d3236..c02b2b6 100644
@@ -129,13 +129,17 @@ int ttm_eu_reserve_buffers(struct list_head *list)
        entry = list_first_entry(list, struct ttm_validate_buffer, head);
        glob = entry->bo->glob;
 
-retry:
        spin_lock(&glob->lru_lock);
        val_seq = entry->bo->bdev->val_seq++;
 

Quoted 12 lines

drivers/gpu/drm/ttm/ttm_execbuf_util.c int ttm_eu_reserve_buffers(struct list_head *list) · line 135

Quoted 1 line

drivers/gpu/drm/ttm/ttm_execbuf_util.c +1 -0

+retry:

After more thinking while i was going over patches to send comment i think this one is bad, really bad. So here is bad case i see, we have a list of 2 bo A & B. We succeed reserving A we set seq_valid to true and val_seq to our val_seq. We fail on B, we go slow path and unreserve A. Some other CPU reserve A but before it write either seq_valid or val_seq we wakeup reserve B and retry to reserve A in reserve_nolru we see A as reserved we enter the while loop see seq_valid set and test val_seq against our same old val_seq we got == and return -EDEADLCK which is definitly not what we want to do. If we inc val seq on retry we will never have this case. So what exactly not incrementing it gave us ?

Hm, that would indeed be a valid problem.

Annoyingly, I can't do the conversion to mutexes until the end of the patchset.
I solved this in the ticket mutexes by making the seqno an atomic, which is unset before unlocking. But doing this with the current ttm code would force extra wake_up_all's inside the reserve path, since we lack the slowpath handling mutexes have.

Nouveau would run into the same problems already with patch 1, so perhaps we could disable the -EDEADLK handling and sleep in that case for now? Afaict, it's a driver error if -EDEADLK occurs.

If performance is unimportant unset seq_valid before unreserving,
and add a smp_wmb between seqno and seqno_valid assignments.
wake_up_all() would be called unconditionally during reservation then, but that call is expensive..

Quoted 3 lines

I think the read and write memory barrier i was talking in patch 1 should avoid any such things to happen but i need to sleep on that to make nightmare about all things that can go wrong.

No it wouldn't help, still a race immediately after the xchg call. :-(

~Maarten

There should no longer be assumptions that reserve will always succeed with the lru lock held, so we can safely break the whole atomic reserve/lru thing. As a bonus this fixes most lockdep annotations for reservations.

Signed-off-by Maarten Lankhorst <[email protected]>

---
 drivers/gpu/drm/ttm/ttm_bo.c           | 54 ++++++++++++++++++++++------------
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  2 +-
 include/drm/ttm/ttm_bo_driver.h        | 19 +++---------
 3 files changed, 40 insertions(+), 35 deletions(-)

drivers/gpu/drm/ttm/ttm_bo.c +1 -1

index 9028327..61b5cd0 100644
@@ -213,14 +213,13 @@ int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
        return put_count;
 }
 
-int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
+int ttm_bo_reserve_nolru(struct ttm_buffer_object *bo,
                          bool interruptible,

drivers/gpu/drm/ttm/ttm_bo.c +4 -4

@@ -241,26 +240,36 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
                if (no_wait)
                        return -EBUSY;
 
-               spin_unlock(&glob->lru_lock);
                ret = ttm_bo_wait_unreserved(bo, interruptible);
-               spin_lock(&glob->lru_lock);
 
                if (unlikely(ret))
                        return ret;
        }
 
-       atomic_set(&bo->reserved, 1);
        if (use_sequence) {
+               bool wake_up = false;
                /**
                 * Wake up waiters that may need to recheck for deadlock,
                 * if we decreased the sequence number.
                 */
                if (unlikely((bo->val_seq - sequence < (1 << 31))
                             || !bo->seq_valid))
-                       wake_up_all(&bo->event_queue);
+                       wake_up = true;
 
+               /*
+                * In the worst case with memory ordering these values can be

drivers/gpu/drm/ttm/ttm_bo.c +21 -12

+               if (wake_up)
+                       wake_up_all(&bo->event_queue);
        } else {
                bo->seq_valid = false;
        }

@@ -289,14 +298,14 @@ int ttm_bo_reserve(struct ttm_buffer_object *bo,
        int put_count = 0;
        int ret;
 
-       spin_lock(&glob->lru_lock);
-       ret = ttm_bo_reserve_locked(bo, interruptible, no_wait, use_sequence,
-                                   sequence);
-       if (likely(ret == 0))
+       ret = ttm_bo_reserve_nolru(bo, interruptible, no_wait, use_sequence,
+                                  sequence);
+       if (likely(ret == 0)) {
+               spin_lock(&glob->lru_lock);
                put_count = ttm_bo_del_from_lru(bo);
-       spin_unlock(&glob->lru_lock);
-
-       ttm_bo_list_ref_sub(bo, put_count, true);
+               spin_unlock(&glob->lru_lock);
+               ttm_bo_list_ref_sub(bo, put_count, true);
+       }
 
        return ret;
 }

@@ -510,7 +519,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct ttm_buffer_object *bo)
        int ret;
 
        spin_lock(&glob->lru_lock);
-       ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+       ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
 
        spin_lock(&bdev->fence_lock);
        (void) ttm_bo_wait(bo, false, false, true);

@@ -603,7 +612,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo,
                        return ret;
 
                spin_lock(&glob->lru_lock);
-               ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+               ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
 
                /*
                 * We raced, and lost, someone else holds the reservation now,

@@ -667,7 +676,14 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all)
                        kref_get(&nentry->list_kref);
                }
 
-               ret = ttm_bo_reserve_locked(entry, false, !remove_all, false, 0);
+               ret = ttm_bo_reserve_nolru(entry, false, true, false, 0);
+               if (remove_all && ret) {
+                       spin_unlock(&glob->lru_lock);
+                       ret = ttm_bo_reserve_nolru(entry, false, false,
+                                                  false, 0);
+                       spin_lock(&glob->lru_lock);
+               }
+
                if (!ret)
                        ret = ttm_bo_cleanup_refs_and_unlock(entry, false,
                                                             !remove_all);

@@ -818,7 +834,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
 
        spin_lock(&glob->lru_lock);
        list_for_each_entry(bo, &man->lru, lru) {
-               ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+               ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
                if (!ret)
                        break;
        }

@@ -1799,7 +1815,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
 
        spin_lock(&glob->lru_lock);
        list_for_each_entry(bo, &glob->swap_lru, swap) {
-               ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+               ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
                if (!ret)
                        break;
        }

drivers/gpu/drm/ttm/ttm_execbuf_util.c +1 -1

index cd9e452..bd37b5c 100644
@@ -153,7 +153,7 @@ retry:
                struct ttm_buffer_object *bo = entry->bo;
 
 retry_this_bo:
-               ret = ttm_bo_reserve_locked(bo, true, true, true, val_seq);
+               ret = ttm_bo_reserve_nolru(bo, true, true, true, val_seq);
                switch (ret) {
                case 0:
                        break;

include/drm/ttm/ttm_bo_driver.h +4 -16

index e3a43a4..6fff432 100644
@@ -790,16 +790,7 @@ extern void ttm_mem_io_unlock(struct ttm_mem_type_manager *man);
  * to make room for a buffer already reserved. (Buffers are reserved before
  * they are evicted). The following algorithm prevents such deadlocks from
  * occurring:
- * 1) Buffers are reserved with the lru spinlock held. Upon successful
- * reservation they are removed from the lru list. This stops a reserved buffer
- * from being evicted. However the lru spinlock is released between the time
- * a buffer is selected for eviction and the time it is reserved.
- * Therefore a check is made when a buffer is reserved for eviction, that it
- * is still the first buffer in the lru list, before it is removed from the
- * list. @check_lru == 1 forces this check. If it fails, the function returns
- * -EINVAL, and the caller should then choose a new buffer to evict and repeat
- * the procedure.
- * 2) Processes attempting to reserve multiple buffers other than for eviction,
+ * Processes attempting to reserve multiple buffers other than for eviction,
  * (typically execbuf), should first obtain a unique 32-bit
  * validation sequence number,
  * and call this function with @use_sequence == 1 and @sequence == the unique

@@ -832,7 +823,7 @@ extern int ttm_bo_reserve(struct ttm_buffer_object *bo,
 
 
 /**
- * ttm_bo_reserve_locked:
+ * ttm_bo_reserve_nolru:
  *
  * @bo: A pointer to a struct ttm_buffer_object.
  * @interruptible: Sleep interruptible if waiting.

@@ -840,9 +831,7 @@ extern int ttm_bo_reserve(struct ttm_buffer_object *bo,
  * @use_sequence: If @bo is already reserved, Only sleep waiting for
  * it to become unreserved if @sequence < (@bo)->sequence.
  *
- * Must be called with struct ttm_bo_global::lru_lock held,
- * and will not remove reserved buffers from the lru lists.
- * The function may release the LRU spinlock if it needs to sleep.
+ * Will not remove reserved buffers from the lru lists.
  * Otherwise identical to ttm_bo_reserve.
  *
  * Returns:

@@ -855,7 +844,7 @@ extern int ttm_bo_reserve(struct ttm_buffer_object *bo,
  * -EDEADLK: Bo already reserved using @sequence. This error code will only
  * be returned if @use_sequence is set to true.
  */
-extern int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
+extern int ttm_bo_reserve_nolru(struct ttm_buffer_object *bo,
                                 bool interruptible,
                                 bool no_wait, bool use_sequence,
                                 uint32_t sequence);
--

1.8.0

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Quoted 28 lines · Maarten Lankhorst

There should no longer be assumptions that reserve will always succeed with the lru lock held, so we can safely break the whole atomic reserve/lru thing. As a bonus this fixes most lockdep annotations for reservations.

Signed-off-by Maarten Lankhorst <[email protected]>

---
 drivers/gpu/drm/ttm/ttm_bo.c           | 54 ++++++++++++++++++++++------------
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  2 +-
 include/drm/ttm/ttm_bo_driver.h        | 19 +++---------
 3 files changed, 40 insertions(+), 35 deletions(-)

drivers/gpu/drm/ttm/ttm_bo.c +1 -2

index 9028327..61b5cd0 100644
@@ -213,14 +213,13 @@ int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
        return put_count;
 }
 
-int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
+int ttm_bo_reserve_nolru(struct ttm_buffer_object *bo,
                          bool interruptible,
                          bool no_wait, bool use_sequence, uint32_t sequence)
 {
-       struct ttm_bo_global *glob = bo->glob;
        int ret;
 

drivers/gpu/drm/ttm/ttm_bo.c int ttm_bo_del_from_lru(struct ttm_buffer_object *bo) · line 225

Quoted 5 lines

drivers/gpu/drm/ttm/ttm_bo.c +1 -1

-       while (unlikely(atomic_read(&bo->reserved) != 0)) {
+       while (unlikely(atomic_xchg(&bo->reserved, 1) != 0)) {
                /**
                 * Deadlock avoidance for multi-bo reserving.
                 */

Regarding memory barrier discussion we could add a smp_rdmb here or few line below before the read of sequence for -EAGAIN. But it's not really important, if a CPU doesn't see new sequence value the worst case is that the CPU will go to wait again before reaching back this section and returning EAGAIN. So it's just gonna waste some CPU cycle i can't see anything bad that could happen.

Quoted 24 lines

drivers/gpu/drm/ttm/ttm_bo.c +2 -4

@@ -241,26 +240,36 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
                if (no_wait)
                        return -EBUSY;
 
-               spin_unlock(&glob->lru_lock);
                ret = ttm_bo_wait_unreserved(bo, interruptible);
-               spin_lock(&glob->lru_lock);
 
                if (unlikely(ret))
                        return ret;
        }
 
-       atomic_set(&bo->reserved, 1);
        if (use_sequence) {
+               bool wake_up = false;
                /**
                 * Wake up waiters that may need to recheck for deadlock,
                 * if we decreased the sequence number.
                 */
                if (unlikely((bo->val_seq - sequence < (1 << 31))
                             || !bo->seq_valid))
-                       wake_up_all(&bo->event_queue);
+                       wake_up = true;
 

drivers/gpu/drm/ttm/ttm_bo.c int ttm_bo_reserve_locked(struct ttm_buffer_object *bo, · line 270

Quoted 12 lines

drivers/gpu/drm/ttm/ttm_bo.c +10 -0

+               /*
+                * In the worst case with memory ordering these values can be
+                * seen in the wrong order. However since we call wake_up_all
+                * in that case, this will hopefully not pose a problem,
+                * and the worst case would only cause someone to accidentally
+                * hit -EAGAIN in ttm_bo_reserve when they see old value of
+                * val_seq. However this would only happen if seq_valid was
+                * written before val_seq was, and just means some slightly
+                * increased cpu usage
+                */
                bo->val_seq = sequence;
                bo->seq_valid = true;

If we want we could add smp_wrmb here but see above comment on usefullness of this.

With all the previous patches there shouldn't be anything lying on the reservations being atomic with removal of the bo's from the lru lists any more.

As such we can finally fix the locking primitives and make it act like normal mutex calls.

Patch 1 is the actual removal of the guarantee in ttm_bo_reserve patch 2 is a cleanup of ttm_eu_backoff_reservation from removing that guarantee patch 3...6 are introducing ttm_bo_reserve_slowpath.

After this series, this should directly map to my proposed extensions to mutex.

With all the previous patches there shouldn't be anything lying on the reservations being atomic with removal of the bo's from the lru lists any more.

As such we can finally fix the locking primitives and make it act like normal mutex calls.

Patch 1 is the actual removal of the guarantee in ttm_bo_reserve patch 2 is a cleanup of ttm_eu_backoff_reservation from removing that guarantee patch 3...6 are introducing ttm_bo_reserve_slowpath.

After this series, this should directly map to my proposed extensions to mutex.

Quoted 9 lines · Maarten Lankhorst

With all the previous patches there shouldn't be anything lying on the reservations being atomic with removal of the bo's from the lru lists any more.

As such we can finally fix the locking primitives and make it act like normal mutex calls.

Patch 1 is the actual removal of the guarantee in ttm_bo_reserve patch 2 is a cleanup of ttm_eu_backoff_reservation from removing that guarantee patch 3...6 are introducing ttm_bo_reserve_slowpath.

Quoted 1 line

After this series, this should directly map to my proposed extensions to mutex.

For the series :

Reviewed-by Jerome Glisse <[email protected]>

Few comments in some patches but nothing important.