[Intel-gfx] [PATCH 30/34] drm/i915: Keep timeline HWSP allocated until the system is idle

[Chris Wilson]

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