Op 06-12-12 02:19, Jerome Glisse schreef:
> On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst
> <m.b.lankhorst@xxxxxxxxx> wrote:
>> 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 <maarten.lankhorst@xxxxxxxxxxxxx>
>> ---
>> 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(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 9028327..61b5cd0 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -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;
>>
>> - 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.
Ah indeed, no bad thing can happen from what I can tell.
I looked at Documentation/atomic_ops.txt again, and it says:
"If a caller requires memory barrier semantics around an atomic_t
operation which does not return a value, opsa set of interfaces are
defined which accomplish this:"
Since we check the value of atomic_xchg, I think that means memory barriers are implied,
strengthened by the fact that the arch specific xchg implementations I checked (x86 and sparc) clobber
memory, which definitely implies a compiler barrier at least, that should be good enough here. Parisc
has no native xchg op and falls back to using spin_lock_irqrestore, so it would definitely be good enough
there.
>> @@ -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
>> + * 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.
Yeah would be overkill. The wake_up_all takes an irqoff spinlock, which would implicitly
count as full memory barrier, and the lru lock will always be taken afterwards, which is
definitely a full memory barrier.
~Maarten
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
