Re: [PATCH 06/16] drm/gem/shrinker: Wait before acquiring struct_mutex under oom

Joonas Lahtinen
2016-08-04T06:47:01Z

On ma, 2016-08-01 at 19:22 +0100, Chris Wilson wrote:
> We can now wait for the GPU (all engines) to become idle without
> requiring the struct_mutex. Inside the shrinker, we need to currently
> take the struct_mutex in order to purge objects and to purge the objects
> we need the GPU to be idle - causing a stall whilst we hold the
> struct_mutex. We can hide most of that stall by performing the wait
> before taking the struct_mutex and only doing essential waits for
> new rendering on objects to be freed.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem_shrinker.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index 1341cb55b6f1..43e53e419982 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -326,9 +326,14 @@ i915_gem_shrinker_lock_uninterruptible(struct drm_i915_private *dev_priv,
>   unsigned long timeout = msecs_to_jiffies(timeout_ms) + 1;
>
>   while (!i915_gem_shrinker_lock(&dev_priv->drm, &slu->unlock)) {
> + if (i915_gem_wait_for_idle(dev_priv) == 0 &&

continue would be much cleaner here, to avoid repeating the lock
calling line? Or how likely is it for engines to be idle but
struct_mutex held for extended period?

Regards, Joonas

> +     i915_gem_shrinker_lock(&dev_priv->drm, &slu->unlock))
> + break;
> +
>   schedule_timeout_killable(1);
>   if (fatal_signal_pending(current))
>   return false;
> +
>   if (--timeout == 0) {
>   pr_err("Unable to lock GPU to purge memory.\n");
>   return false;
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation