From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, sourab.gupta@intel.com,
Akash Goel <akash.goel@intel.com>
Subject: Re: [PATCH] drm/i915: Disable shrinker for non-swapped backed objects
Date: Tue, 24 Nov 2015 18:15:47 +0100 [thread overview]
Message-ID: <20151124171547.GW17050@phenom.ffwll.local> (raw)
In-Reply-To: <1448270424-16612-1-git-send-email-chris@chris-wilson.co.uk>
On Mon, Nov 23, 2015 at 09:20:24AM +0000, Chris Wilson wrote:
> If the system has no available swap pages, we cannot make forward
> progress in the shrinker by releasing active pages, only by releasing
> purgeable pages which are immediately reaped. Take total_swap_pages into
> account when counting up available objects to be shrunk and subsequently
> shrinking them. By doing so, we avoid unbinding objects that cannot be
> shrunk and so wasting CPU cycles flushing those objects from the GPU to
> the system and then immediately back again (as they will more than
> likely be reused shortly after).
>
> Based on a patch by Akash Goel.
>
> Reported-by: Akash Goel <akash.goel@intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Akash Goel <akash.goel@intel.com>
> Cc: sourab.gupta@intel.com
Cc: linux-mm@kvack.org should be done on this one, just in case they have
ideas for proper interfaces for this. Which might be, given that Jerome
Glisse is working on swaput-to-vram and other fun stuff like that.
Also, how does stuff like zswap (or whatever "compress my swap in memory"
is called again) factor in here? Iirc Android very much does use that.
i915 side looks fine, but I'd like an ack from a core mm hacker for this.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 55 ++++++++++++++++++++++----------
> 1 file changed, 39 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index f7df54a8ee2b..0823f321b7de 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -47,6 +47,41 @@ static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
> #endif
> }
>
> +static int num_vma_bound(struct drm_i915_gem_object *obj)
> +{
> + struct i915_vma *vma;
> + int count = 0;
> +
> + list_for_each_entry(vma, &obj->vma_list, vma_link) {
> + if (drm_mm_node_allocated(&vma->node))
> + count++;
> + if (vma->pin_count)
> + count++;
> + }
> +
> + return count;
> +}
> +
> +static bool can_release_pages(struct drm_i915_gem_object *obj)
> +{
> + /* Only report true if by unbinding the object and putting its pages
> + * we can actually make forward progress towards freeing physical
> + * pages.
> + *
> + * If the pages are pinned for any other reason than being bound
> + * to the GPU, simply unbinding from the GPU is not going to succeed
> + * in release our pin count on the pages themselves.
> + */
> + if (obj->pages_pin_count != num_vma_bound(obj))
> + return false;
> +
> + /* We can only return physical pages if we either discard them
> + * (because the user has marked them as being purgeable) or if
> + * we can move their contents out to swap.
> + */
> + return total_swap_pages || obj->madv == I915_MADV_DONTNEED;
> +}
> +
> /**
> * i915_gem_shrink - Shrink buffer object caches
> * @dev_priv: i915 device
> @@ -129,6 +164,9 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
> if ((flags & I915_SHRINK_ACTIVE) == 0 && obj->active)
> continue;
>
> + if (!can_release_pages(obj))
> + continue;
> +
> drm_gem_object_reference(&obj->base);
>
> /* For the unbound phase, this should be a no-op! */
> @@ -188,21 +226,6 @@ static bool i915_gem_shrinker_lock(struct drm_device *dev, bool *unlock)
> return true;
> }
>
> -static int num_vma_bound(struct drm_i915_gem_object *obj)
> -{
> - struct i915_vma *vma;
> - int count = 0;
> -
> - list_for_each_entry(vma, &obj->vma_list, vma_link) {
> - if (drm_mm_node_allocated(&vma->node))
> - count++;
> - if (vma->pin_count)
> - count++;
> - }
> -
> - return count;
> -}
> -
> static unsigned long
> i915_gem_shrinker_count(struct shrinker *shrinker, struct shrink_control *sc)
> {
> @@ -222,7 +245,7 @@ i915_gem_shrinker_count(struct shrinker *shrinker, struct shrink_control *sc)
> count += obj->base.size >> PAGE_SHIFT;
>
> list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
> - if (!obj->active && obj->pages_pin_count == num_vma_bound(obj))
> + if (!obj->active && can_release_pages(obj))
> count += obj->base.size >> PAGE_SHIFT;
> }
>
> --
> 2.6.2
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-11-24 17:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 9:20 [PATCH] drm/i915: Disable shrinker for non-swapped backed objects Chris Wilson
2015-11-24 17:15 ` Daniel Vetter [this message]
2015-11-24 23:17 ` Chris Wilson
2015-11-25 9:17 ` Daniel Vetter
2015-11-25 9:58 ` Chris Wilson
2015-11-25 13:36 ` Goel, Akash
2015-11-26 9:34 ` Daniel Vetter
2015-11-26 10:30 ` Chris Wilson
2015-11-26 11:36 ` Daniel Vetter
2015-11-25 18:36 ` [PATCH v2] " Chris Wilson
2015-11-25 18:53 ` Chris Wilson
2015-11-25 19:06 ` Johannes Weiner
2015-11-25 20:31 ` Chris Wilson
2015-11-25 20:46 ` Johannes Weiner
2015-11-26 11:25 ` Chris Wilson
2015-11-26 15:40 ` Johannes Weiner
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=20151124171547.GW17050@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=akash.goel@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=sourab.gupta@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox