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

Chris Wilson chris at chris-wilson.co.uk
Mon Aug 5 16:54:19 UTC 2019

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.
> 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.

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.

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.

More information about the dri-devel mailing list