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
