From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/6] drm/i915: Remove walk over obj->vma_list for the shrinker
Date: Tue, 15 Aug 2017 17:56:07 +0300 [thread overview]
Message-ID: <1502808967.4217.19.camel@linux.intel.com> (raw)
In-Reply-To: <20170812115122.10854-2-chris@chris-wilson.co.uk>
On Sat, 2017-08-12 at 12:51 +0100, Chris Wilson wrote:
> In the next patch, we want to reduce the lock coverage within the
> shrinker, and one of the dangerous walks we have is over obj->vma_list.
> We are only walking the obj->vma_list in order to check whether it has
> been permanently pinned by HW access, typically via use on the scanout.
> But we have a couple of other long term pins, the context objects for
> which we currently have to check the individual vma pin_count. If we
> instead mark these using obj->pin_display, we can forgo the dangerous
> and sometimes slow list iteration.
s/pin_display/pin_permanent/g
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
<SNIP>
> static bool swap_available(void)
> {
> return get_nr_swap_pages() > 0;
> @@ -115,7 +96,13 @@ static bool can_release_pages(struct drm_i915_gem_object *obj)
> if (atomic_read(&obj->mm.pages_pin_count) > obj->bind_count)
> return false;
>
> - if (any_vma_pinned(obj))
> + /* If any vma are permanently pinned, it will prevent us from reclaiming
Oh, it sounds so much better here when the variable is 'pin_permanent'.
> + * the obj->mm.pages. We only allow scanout objects to claim a permanent
> + * pin, along with a few others like the reserved context object. To
> + * simplify the scan, and to avoid walking the list of vma under the
> + * object, we just check the count of its permanently pinned.
> + */
> + if (obj->pin_display)
> return false;
>
> /* We can only return physical pages to the system if we can either
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index b0738d2b2a7f..874562bd59ae 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -866,6 +866,7 @@ execlists_context_pin(struct intel_engine_cs *engine,
> i915_ggtt_offset(ce->ring->vma);
>
> ce->state->obj->mm.dirty = true;
> + ce->state->obj->pin_display++;
This should be closer to intel_ring_pin (my preference).
>
> i915_gem_context_get(ctx);
> out:
> @@ -892,6 +893,7 @@ static void execlists_context_unpin(struct intel_engine_cs *engine,
> return;
>
> intel_ring_unpin(ce->ring);
> + ce->state->obj->pin_display--;
Or this should be closer to i915_gem_context_put. Just make it
symmetrict.
> @@ -1515,6 +1517,7 @@ intel_ring_context_pin(struct intel_engine_cs *engine,
> if (ret)
> goto err;
>
> + ce->state->obj->pin_display++;
> ce->state->obj->mm.dirty = true;
This is rather symmetric, the above can have mm.dirty after it, too.
As 'pin_permanent', this is;
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-08-15 14:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-12 11:51 [PATCH 1/6] drm/i915: Refactor testing obj->mm.pages Chris Wilson
2017-08-12 11:51 ` [PATCH 2/6] drm/i915: Remove walk over obj->vma_list for the shrinker Chris Wilson
2017-08-15 14:56 ` Joonas Lahtinen [this message]
2017-08-15 15:05 ` Chris Wilson
2017-08-15 16:17 ` [PATCH 1/2] drm/i915: Rename obj->pin_display to obj->pin_global Chris Wilson
2017-08-15 16:17 ` [PATCH 2/2] drm/i915: Drop debugfs/i915_gem_pin_display Chris Wilson
2017-08-12 11:51 ` [PATCH 3/6] drm/i915: Move dev_priv->mm.[un]bound_list to its own lock Chris Wilson
2017-08-16 13:13 ` Joonas Lahtinen
2017-08-12 11:51 ` [PATCH 4/6] drm/i915: Set our shrinker->batch to 4096 (~16MiB) Chris Wilson
2017-08-16 13:39 ` Joonas Lahtinen
2017-08-16 13:55 ` Chris Wilson
2017-08-16 14:23 ` [PATCH v2] " Chris Wilson
2017-08-18 12:56 ` Chris Wilson
2017-08-18 22:48 ` Chris Wilson
2017-09-20 13:28 ` [PATCH 4/6] " Joonas Lahtinen
2017-09-26 15:02 ` Chris Wilson
2017-09-27 8:38 ` Joonas Lahtinen
2017-09-27 8:54 ` Chris Wilson
2017-08-12 11:51 ` [PATCH 5/6] drm/i915: Trim struct_mutex hold duration for i915_gem_free_objects Chris Wilson
2017-08-12 11:51 ` [PATCH 6/6] drm/i915: Only free the oldest stale object before a fresh allocation Chris Wilson
2017-08-16 13:53 ` Joonas Lahtinen
2017-08-12 12:09 ` ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Refactor testing obj->mm.pages Patchwork
2017-08-15 16:46 ` ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Refactor testing obj->mm.pages (rev3) Patchwork
2017-08-16 14:54 ` ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Refactor testing obj->mm.pages (rev4) 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=1502808967.4217.19.camel@linux.intel.com \
--to=joonas.lahtinen@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.