Quoting Tvrtko Ursulin (2018-01-15 16:54:57) > > In general it is a bit funky to call_rcu to schedule worker - what would > be the difference to just queueing the worker which would have > synchronize rcu in it? The complication came from introducing the direct cleanup path to penalise frequent reallocations, and to avoid deferring unbounded work to the rcu task (which shows up in our microbenchmarks as a significant drawback). > Or would it be feasible to do multi-pass - 1st pass directly from > call_rcu does the ones which can be done wo/ struct mutex, leaves the > rest on the list and queues more thorough 2nd pass. Haven't really > investigated it, just throwing ideas around. We need to take the mutex first in the release pass (to release the GPU binding before we return the resources back to the system). There is a nicety in doing most of the operations in the worker context rather than in process (deferring the work to later, with some penalty applied to frequent reallocation) or rcu context. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
