[Intel-gfx] [PATCH 30/34] drm/i915: Keep timeline HWSP allocated until the system is idle
Chris Wilson
chris at chris-wilson.co.uk
Mon Jan 21 22:37:13 UTC 2019
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.
How does that help? Good question.
-Chris
More information about the Intel-gfx
mailing list