From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 8/9] drm/i915: Only free the oldest stale object before a fresh allocation
Date: Mon, 16 Oct 2017 13:54:24 +0300 [thread overview]
Message-ID: <1508151264.5300.29.camel@linux.intel.com> (raw)
In-Reply-To: <20171013202621.7276-8-chris@chris-wilson.co.uk>
On Fri, 2017-10-13 at 21:26 +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
"we also want do not want to", maybe just "we also do not want to"
> 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
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-10-16 10:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 20:26 [PATCH 1/9] drm/i915: Refactor testing obj->mm.pages Chris Wilson
2017-10-13 20:26 ` [PATCH 2/9] drm/i915: Rename obj->pin_display to obj->pin_global Chris Wilson
2017-10-16 10:40 ` Joonas Lahtinen
2017-10-13 20:26 ` [PATCH 3/9] drm/i915: Drop debugfs/i915_gem_pin_display Chris Wilson
2017-10-16 10:41 ` Joonas Lahtinen
2017-10-13 20:26 ` [PATCH 4/9] drm/i915: Remove walk over obj->vma_list for the shrinker Chris Wilson
2017-10-13 20:26 ` [PATCH 5/9] drm/i915: Move dev_priv->mm.[un]bound_list to its own lock Chris Wilson
2017-10-13 22:36 ` [PATCH v2] " Chris Wilson
2017-10-13 23:23 ` [PATCH v3] " Chris Wilson
2017-10-16 11:40 ` Chris Wilson
2017-10-13 20:26 ` [PATCH 6/9] drm/i915: Wire up shrinkctl->nr_scanned Chris Wilson
2017-10-16 10:46 ` Joonas Lahtinen
2017-10-16 10:51 ` Chris Wilson
2017-10-16 12:57 ` Joonas Lahtinen
2017-10-13 20:26 ` [PATCH 7/9] drm/i915: Set our shrinker->batch to 4096 (~16MiB) Chris Wilson
2017-10-13 20:26 ` [PATCH 8/9] drm/i915: Only free the oldest stale object before a fresh allocation Chris Wilson
2017-10-16 10:54 ` Joonas Lahtinen [this message]
2017-10-13 20:26 ` [PATCH 9/9] drm/i915: Trim struct_mutex hold duration for i915_gem_free_objects Chris Wilson
2017-10-13 21:46 ` ✗ Fi.CI.BAT: warning for series starting with [1/9] drm/i915: Refactor testing obj->mm.pages Patchwork
2017-10-13 22:32 ` Chris Wilson
2017-10-13 23:12 ` ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915: Refactor testing obj->mm.pages (rev2) Patchwork
2017-10-13 23:51 ` ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915: Refactor testing obj->mm.pages (rev3) Patchwork
2017-10-16 12:10 ` ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Refactor testing obj->mm.pages (rev4) Patchwork
2017-10-16 20:12 ` ✗ Fi.CI.IGT: failure " 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=1508151264.5300.29.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.