Re: [PATCH 1/5] drm/i915: stop pruning reservation object after wait

["Christian König" <ckoenig.leichtzumerken@gmail.com>]

Am 05.08.19 um 18:54 schrieb Chris Wilson:
> Quoting Chris Wilson (2019-08-05 16:58:56)
>> Quoting Christian König (2019-08-05 16:45:50)
>>> The reservation object should be capable of handling its internal memory
>>> management itself. And since we search for a free slot to add the fence
>>> from the beginning this is actually a waste of time and only minimal helpful.
>> "From the beginning?" Attempting to prune signaled fences on insertion is
>> quite recent.

What I meant was from the beginning of the array :) Sorry for the confusion.

>> However, that doesn't help the cases where reservation_object keeps on
>> holding a reference to the fences for idle objects. It's an absolute
>> nightmare of a reference trap.

We only free up the fence objects, but not the array itself. And 
userspace actually needs to call the wait function.

So to me this looks like it doesn't really helps much.

> Fwiw, it's a pet peeve, and not a fundamental object to removing some
> loops inside reservation_object. Here, the seqno is being used as a
> guide to avoid trying to take the lock if it's been externally modified,
> but it would equally work with just a plain trylock + test_rcu.

Ok, going to do this then for the meantime.

> Better yet would be autopruning, but that suggests a slightly different
> data structure an rbtree instead of an array and spinlocked cb_list
> manipulation instead of a plain refcount.

Yeah, that's exactly what I'm working on with this series.

Regards,
Christian.

> -Chris

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel