From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH 4/4] drm/i915: Invalidate our pages under memory pressure
Date: Tue, 20 May 2014 09:53:28 +0200 [thread overview]
Message-ID: <20140520075328.GA8790@phenom.ffwll.local> (raw)
In-Reply-To: <1395753786-6442-4-git-send-email-chris@chris-wilson.co.uk>
On Tue, Mar 25, 2014 at 01:23:06PM +0000, Chris Wilson wrote:
> Try to flush out dirty pages into the swapcache (and from there into the
> swapfile) when under memory pressure and forced to drop GEM objects from
> memory. In effect, this should just allow us to discard unused pages for
> memory reclaim and to start writeback earlier.
>
> v2: Hugh Dickins warned that explicitly starting writeback from
> shrink_slab was prone to deadlocks within shmemfs.
>
> Cc: Hugh Dickins <hughd@google.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Merged all four patches. Can you please go through bugzilla and poke all
relevant patches for retesting? I think I've made a sufficient fool of
myself yesterday to not attempt this ;-)
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 38 +++++++++++++++++++++++++++-----------
> 1 file changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 135ee8bd55f6..8287fd6701c6 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -60,7 +60,6 @@ static unsigned long i915_gem_shrinker_scan(struct shrinker *shrinker,
> struct shrink_control *sc);
> static unsigned long i915_gem_purge(struct drm_i915_private *dev_priv, long target);
> static unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv);
> -static void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
> static void i915_gem_retire_requests_ring(struct intel_ring_buffer *ring);
>
> static bool cpu_cache_is_coherent(struct drm_device *dev,
> @@ -1685,12 +1684,16 @@ i915_gem_mmap_gtt_ioctl(struct drm_device *dev, void *data,
> return i915_gem_mmap_gtt(file, dev, args->handle, &args->offset);
> }
>
> +static inline int
> +i915_gem_object_is_purgeable(struct drm_i915_gem_object *obj)
> +{
> + return obj->madv == I915_MADV_DONTNEED;
> +}
> +
> /* Immediately discard the backing storage */
> static void
> i915_gem_object_truncate(struct drm_i915_gem_object *obj)
> {
> - struct inode *inode;
> -
> i915_gem_object_free_mmap_offset(obj);
>
> if (obj->base.filp == NULL)
> @@ -1701,16 +1704,28 @@ i915_gem_object_truncate(struct drm_i915_gem_object *obj)
> * To do this we must instruct the shmfs to drop all of its
> * backing pages, *now*.
> */
> - inode = file_inode(obj->base.filp);
> - shmem_truncate_range(inode, 0, (loff_t)-1);
> -
> + shmem_truncate_range(file_inode(obj->base.filp), 0, (loff_t)-1);
> obj->madv = __I915_MADV_PURGED;
> }
>
> -static inline int
> -i915_gem_object_is_purgeable(struct drm_i915_gem_object *obj)
> +/* Try to discard unwanted pages */
> +static void
> +i915_gem_object_invalidate(struct drm_i915_gem_object *obj)
> {
> - return obj->madv == I915_MADV_DONTNEED;
> + struct address_space *mapping;
> +
> + switch (obj->madv) {
> + case I915_MADV_DONTNEED:
> + i915_gem_object_truncate(obj);
> + case __I915_MADV_PURGED:
> + return;
> + }
> +
> + if (obj->base.filp == NULL)
> + return;
> +
> + mapping = file_inode(obj->base.filp)->i_mapping,
> + invalidate_mapping_pages(mapping, 0, (loff_t)-1);
> }
>
> static void
> @@ -1775,8 +1790,7 @@ i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
> ops->put_pages(obj);
> obj->pages = NULL;
>
> - if (i915_gem_object_is_purgeable(obj))
> - i915_gem_object_truncate(obj);
> + i915_gem_object_invalidate(obj);
>
> return 0;
> }
> @@ -4201,6 +4215,8 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
>
> if (WARN_ON(obj->pages_pin_count))
> obj->pages_pin_count = 0;
> + if (obj->madv != __I915_MADV_PURGED)
> + obj->madv = I915_MADV_DONTNEED;
> i915_gem_object_put_pages(obj);
> i915_gem_object_free_mmap_offset(obj);
> i915_gem_object_release_stolen(obj);
> --
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-05-20 7:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 13:23 [PATCH 1/4] drm/i915: Translate ENOSPC from shmem_get_page() to ENOMEM Chris Wilson
2014-03-25 13:23 ` [PATCH 2/4] drm/i915: Include bound and active pages in the count of shrinkable objects Chris Wilson
2014-05-19 16:04 ` Barbalho, Rafael
2014-03-25 13:23 ` [PATCH 3/4] drm/i915: Refactor common lock handling between shrinker count/scan Chris Wilson
2014-05-19 16:05 ` Barbalho, Rafael
2014-03-25 13:23 ` [PATCH 4/4] drm/i915: Invalidate our pages under memory pressure Chris Wilson
2014-04-11 8:30 ` Chris Wilson
2014-04-11 8:38 ` Daniel Vetter
2014-04-11 8:46 ` Chris Wilson
2014-04-16 17:13 ` Robert Beckett
2014-04-17 16:34 ` Jani Nikula
2014-04-22 19:06 ` Daniel Vetter
2014-04-22 23:23 ` Robert Beckett
2014-05-19 16:07 ` Barbalho, Rafael
2014-05-20 7:53 ` Daniel Vetter [this message]
2014-05-20 7:56 ` Chris Wilson
2014-05-20 8:12 ` Daniel Vetter
2014-05-19 16:03 ` [PATCH 1/4] drm/i915: Translate ENOSPC from shmem_get_page() to ENOMEM Barbalho, Rafael
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=20140520075328.GA8790@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=hughd@google.com \
--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.