[Intel-gfx] [PATCH] drm/i915: Prefer to reschedule the free_object worker rather than block

[Mika Kuoppala]

Chris Wilson <chris at chris-wilson.co.uk> writes:

> Avoid blocking the kworker by putting back the freed object list if we
> cannot immediately take the mutex. We will try again shortly, and flush
> the work when desperate.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=100434
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index ab77e38ec264..c2e5cb529b0f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4200,7 +4200,19 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915,
>  {
>  	struct drm_i915_gem_object *obj, *on;
>  
> -	mutex_lock(&i915->drm.struct_mutex);
> +	if (!mutex_trylock(&i915->drm.struct_mutex)) {
> +		/* If we fail to acquire the struct_mutex, put back the
> +		 * freed list and we will try again in the future. By
> +		 * rescheduling the task we prevent us from blocking
> +		 * the worker indefinitely on a prolonged wait for
> +		 * struct_mutex.

I don't understand the last part of the comment. If we don't
want a prolonged block due to mutex, should we limit the amount
of work we do here, inside the mutex. By limiting how much we
free per aquiring the lock?

-Mika

> +		 */
> +		if (llist_add_batch(llist_reverse_order(freed), freed,
> +				    &i915->mm.free_list))
> +			schedule_work(&i915->mm.free_work);
> +		return;
> +	}
> +
>  	intel_runtime_pm_get(i915);
>  	llist_for_each_entry(obj, freed, freed) {
>  		struct i915_vma *vma, *vn;
> -- 
> 2.11.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx