From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/6] drm/i915: Only free the oldest stale object before a fresh allocation
Date: Wed, 16 Aug 2017 16:53:59 +0300 [thread overview]
Message-ID: <1502891639.6625.10.camel@linux.intel.com> (raw)
In-Reply-To: <20170812115122.10854-6-chris@chris-wilson.co.uk>
On Sat, 2017-08-12 at 12:51 +0100, Chris Wilson wrote:
> Inspired by Tvrtko's critique of the reaping of the stale contexts
> before allocating a new one, also limit the freed object reaping to the
> oldest stale object before allocating a fresh object. Unlike contexts,
> objects may have radically different sizes of backing storage, but
> similar to contexts, whilst we want to prevent starvation due to
> excessive freed lists, we also want do not want to delay fresh
> allocations for too long. Only freeing the oldest on the freed object
> list before each allocation is a reasonable compromise.
>
> v2: Only a single consumer of llist_del_first() is allowed (although
> multiple llist_add are still allowed in parallel). Unlike
> i915_gem_context, i915_gem_flush_free_objects() is itself not serialized
> and so we need to add our own spinlock. Otherwise KASAN eventually spots
> a use-after-free for the race on *first->next.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1
<SNIP>
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1466,6 +1466,7 @@ struct i915_gem_mm {
> */
> struct llist_head free_list;
> struct work_struct free_work;
> + spinlock_t free_lock;
Please document the scope of this lock here.
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-16 13:54 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
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 [this message]
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=1502891639.6625.10.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.