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. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
