Chris Wilson <[email protected]> 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 <[email protected]>
> ---
> 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
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
