All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 02/26] drm/i915: Skip shrinking already freed pages
Date: Tue, 18 Jun 2019 19:06:36 +0300	[thread overview]
Message-ID: <87muie7u9f.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20190618074153.16055-2-chris@chris-wilson.co.uk>

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

> Previously, we want to shrink the pages of freed objects before they
> were RCU collected. However, by removing the struct_mutex serialisation
> around the active reference, we need to acquire an extra reference
> around the wait. Unfortunately this means that we have to skip objects
> that are waiting RCU collection.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c   | 47 +-------------------
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c |  5 +++
>  2 files changed, 6 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 272ce30ce1d3..1b571fd26ed4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -149,33 +149,6 @@ void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
>  	}
>  }
>  
> -static bool discard_backing_storage(struct drm_i915_gem_object *obj)
> -{
> -	/*
> -	 * If we are the last user of the backing storage (be it shmemfs
> -	 * pages or stolen etc), we know that the pages are going to be
> -	 * immediately released. In this case, we can then skip copying
> -	 * back the contents from the GPU.
> -	 */
> -	if (!i915_gem_object_is_shrinkable(obj))
> -		return false;
> -
> -	if (obj->mm.madv != I915_MADV_WILLNEED)
> -		return false;
> -
> -	if (!obj->base.filp)
> -		return true;
> -
> -	/* At first glance, this looks racy, but then again so would be
> -	 * userspace racing mmap against close. However, the first external
> -	 * reference to the filp can only be obtained through the
> -	 * i915_gem_mmap_ioctl() which safeguards us against the user
> -	 * acquiring such a reference whilst we are in the middle of
> -	 * freeing the object.
> -	 */
> -	return file_count(obj->base.filp) == 1;
> -}
> -
>  static void __i915_gem_free_objects(struct drm_i915_private *i915,
>  				    struct llist_node *freed)
>  {
> @@ -225,8 +198,7 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915,
>  		if (obj->ops->release)
>  			obj->ops->release(obj);
>  
> -		if (WARN_ON(i915_gem_object_has_pinned_pages(obj)))
> -			atomic_set(&obj->mm.pages_pin_count, 0);
> +		atomic_set(&obj->mm.pages_pin_count, 0);
>  		__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
>  		GEM_BUG_ON(i915_gem_object_has_pages(obj));
>  
> @@ -324,23 +296,6 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
>  {
>  	struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
>  
> -	if (obj->mm.quirked)
> -		__i915_gem_object_unpin_pages(obj);
> -
> -	if (discard_backing_storage(obj)) {
> -		struct drm_i915_private *i915 = to_i915(obj->base.dev);
> -
> -		obj->mm.madv = I915_MADV_DONTNEED;
> -
> -		if (i915_gem_object_has_pages(obj)) {
> -			unsigned long flags;
> -
> -			spin_lock_irqsave(&i915->mm.obj_lock, flags);
> -			list_move_tail(&obj->mm.link, &i915->mm.purge_list);
> -			spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
> -		}
> -	}
> -
>  	/*
>  	 * Before we free the object, make sure any pure RCU-only
>  	 * read-side critical sections are complete, e.g.
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index c851c4029597..3a926a8755c6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -241,6 +241,9 @@ i915_gem_shrink(struct drm_i915_private *i915,
>  			if (!can_release_pages(obj))
>  				continue;
>  
> +			if (!kref_get_unless_zero(&obj->base.refcount))
> +				continue;
> +

The comment above, in this function, seems a little bit
stale on talking about struct mutex. Straighten it up.

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

>  			spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
>  
>  			if (unsafe_drop_pages(obj)) {
> @@ -253,7 +256,9 @@ i915_gem_shrink(struct drm_i915_private *i915,
>  				}
>  				mutex_unlock(&obj->mm.lock);
>  			}
> +
>  			scanned += obj->base.size >> PAGE_SHIFT;
> +			i915_gem_object_put(obj);
>  
>  			spin_lock_irqsave(&i915->mm.obj_lock, flags);
>  		}
> -- 
> 2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-06-18 16:06 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-18  7:41 [PATCH 01/26] drm/i915: Keep engine alive as we retire the context Chris Wilson
2019-06-18  7:41 ` [PATCH 02/26] drm/i915: Skip shrinking already freed pages Chris Wilson
2019-06-18 11:59   ` Chris Wilson
2019-06-18 16:06   ` Mika Kuoppala [this message]
2019-06-18 16:22     ` Chris Wilson
2019-06-18  7:41 ` [PATCH 03/26] drm/i915: Stop passing I915_WAIT_LOCKED to i915_request_wait() Chris Wilson
2019-06-19 11:44   ` Mika Kuoppala
2019-06-18  7:41 ` [PATCH 04/26] drm/i915: Flush the execution-callbacks on retiring Chris Wilson
2019-06-19 13:12   ` Mika Kuoppala
2019-06-19 13:18     ` Chris Wilson
2019-06-18  7:41 ` [PATCH 05/26] drm/i915/execlists: Preempt-to-busy Chris Wilson
2019-06-18  7:41 ` [PATCH 06/26] drm/i915/execlists: Minimalistic timeslicing Chris Wilson
2019-06-18  7:41 ` [PATCH 07/26] drm/i915/execlists: Force preemption Chris Wilson
2019-06-18  7:41 ` [PATCH 08/26] drm/i915: Make the semaphore saturation mask global Chris Wilson
2019-06-19 10:45   ` Tvrtko Ursulin
2019-06-18  7:41 ` [PATCH 09/26] dma-fence: Propagate errors to dma-fence-array container Chris Wilson
2019-06-18  7:41 ` [PATCH 10/26] dma-fence: Report the composite sync_file status Chris Wilson
2019-06-18  7:41 ` [PATCH 11/26] dma-fence: Refactor signaling for manual invocation Chris Wilson
2019-06-18  7:41 ` [PATCH 12/26] dma-fence: Always execute signal callbacks Chris Wilson
2019-06-18  7:41 ` [PATCH 13/26] drm/i915: Track i915_active using debugobjects Chris Wilson
2019-06-18  7:41 ` [PATCH 14/26] drm/i915: Signal fence completion from i915_request_wait Chris Wilson
2019-06-18  7:41 ` [PATCH 15/26] drm/i915: Remove waiting & retiring from shrinker paths Chris Wilson
2019-06-18  7:41 ` [PATCH 16/26] drm/i915: Throw away the active object retirement complexity Chris Wilson
2019-06-18  7:41 ` [PATCH 17/26] drm/i915: Provide an i915_active.acquire callback Chris Wilson
2019-06-18  7:41 ` [PATCH 18/26] drm/i915: Push the i915_active.retire into a worker Chris Wilson
2019-06-18  7:41 ` [PATCH 19/26] drm/i915/overlay: Switch to using i915_active tracking Chris Wilson
2019-06-18  7:41 ` [PATCH 20/26] drm/i915: Forgo last_fence active request tracking Chris Wilson
2019-06-18  7:41 ` [PATCH 21/26] drm/i915: Extract intel_frontbuffer active tracking Chris Wilson
2019-06-18  7:41 ` [PATCH 22/26] drm/i915: Coordinate i915_active with its own mutex Chris Wilson
2019-06-18  7:41 ` [PATCH 23/26] drm/i915: Rename intel_wakeref_[is]_active Chris Wilson
2019-06-18  8:14   ` Chris Wilson
2019-06-18  7:41 ` [PATCH 24/26] drm/i915: Teach execbuffer to take the engine wakeref not GT Chris Wilson
2019-06-18  7:41 ` [PATCH 25/26] drm/i915: Replace struct_mutex for batch pool serialisation Chris Wilson
2019-06-18  7:41 ` [PATCH 26/26] drm/i915: Move idle barrier cleanup into engine-pm Chris Wilson
2019-06-18  8:57 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/26] drm/i915: Keep engine alive as we retire the context Patchwork
2019-06-18  9:09 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-06-18  9:18 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-18 13:45 ` [PATCH 01/26] " Mika Kuoppala
2019-06-18 13:59   ` Chris Wilson
2019-06-18 14:03     ` Chris Wilson
2019-06-18 14:08     ` Mika Kuoppala
2019-06-18 19:15 ` ✗ Fi.CI.IGT: failure for series starting with [01/26] " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87muie7u9f.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.