Quoting Chris Wilson (2020-01-13 14:04:07)
> Currently, we only retire the oldest request on the timeline before
> allocating the next, but only if there is a spare request. However,
> since we rearranged the locking, e.g. commit df9f85d8582e ("drm/i915:
> Serialise i915_active_fence_set() with itself"), we no longer benefit
> from keeping the active chain intact underneath the struct_mutex. As
> such, retire all completed requests in the client's timeline before
> creating the next, trying to keep our memory and resource usage tight
> and ideally only penalising the heavy users.
>
> References: df9f85d8582e ("drm/i915: Serialise i915_active_fence_set() with itself")
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/i915_request.c | 44 ++++-------------------------
> 1 file changed, 5 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index 9ed0d3bc7249..5743edb50688 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -558,21 +558,12 @@ request_alloc_slow(struct intel_timeline *tl, gfp_t gfp)
> {
> struct i915_request *rq;
>
> - if (list_empty(&tl->requests))
> - goto out;
> + if (gfpflags_allow_blocking(gfp))
I am an idiot.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
