Quoting Chris Wilson (2019-01-21 22:37:13) > Quoting Chris Wilson (2019-01-21 22:21:13) > > In preparation for enabling HW semaphores, we need to keep in flight > > timeline HWSP alive until the entire system is idle, as any other > > timeline active on the GPU may still refer back to the already retired > > timeline. We both have to delay recycling available cachelines and > > unpinning old HWSP until the next idle point (i.e. on parking). > > > > That we have to keep the HWSP alive for external references on HW raises > > an interesting conundrum. On a busy system, we may never see a global > > idle point, essentially meaning the resource will be leaking until we > > are forced to sleep. What we need is a set of RCU primitives for the GPU! > > This should also help mitigate the resource starvation issues > > promulgating from keeping all logical state pinned until idle (instead > > of as currently handled until the next context switch). > > I was resisting adding all the i915_vma_move_to_active() thinking that > it was overkill, but perhaps that is exactly what I mean by > rcu_read_lock(). Hmm. More so that I was trying to avoid having to keep > moving the HWSP from one request to the next (for the write lock), but > that should be for the normal case covered by the context pinning > itself, and for the realloc we can add a write lock to the next rq. Also because that mechanism is guarded by the struct_mutex and I have an aversion to struct_mutex... -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
