From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Akash Goel <akash.goel@intel.com>
Subject: Re: [PATCH 1/2] drm/i915: Allow overlapping userptr objects
Date: Thu, 10 Jul 2014 13:26:53 +0100 [thread overview]
Message-ID: <53BE868D.8080301@linux.intel.com> (raw)
In-Reply-To: <1404984104-27169-1-git-send-email-chris@chris-wilson.co.uk>
On 07/10/2014 10:21 AM, Chris Wilson wrote:
> Whilst I strongly advise against doing so for the implicit coherency
> issues between the multiple buffer objects accessing the same backing
> store, it nevertheless is a valid use case, akin to mmaping the same
> file multiple times.
>
> The reason why we forbade it earlier was that our use of the interval
> tree for fast invalidation upon vma changes excluded overlapping
> objects. So in the case where the user wishes to create such pairs of
> overlapping objects, we degrade the range invalidation to walkin the
> linear list of objects associated with the mm.
>
> v2: Compile for mmu-notifiers after tweaking
[snip]
> +static void invalidate_range__linear(struct i915_mmu_notifier *mn,
> + struct mm_struct *mm,
> + unsigned long start,
> + unsigned long end)
> +{
> + struct i915_mmu_object *mmu;
> + unsigned long serial;
> +
> +restart:
> + serial = mn->serial;
> + list_for_each_entry(mmu, &mn->linear, link) {
> + struct drm_i915_gem_object *obj;
> +
> + if (mmu->it.last < start || mmu->it.start > end)
> + continue;
> +
> + obj = mmu->obj;
> + drm_gem_object_reference(&obj->base);
> + spin_unlock(&mn->lock);
> +
> + cancel_userptr(obj);
> +
> + spin_lock(&mn->lock);
> + if (serial != mn->serial)
> + goto restart;
> + }
> +
> + spin_unlock(&mn->lock);
> +}
> +
> static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> struct mm_struct *mm,
> unsigned long start,
> @@ -60,16 +128,19 @@ static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> {
> struct i915_mmu_notifier *mn = container_of(_mn, struct i915_mmu_notifier, mn);
> struct interval_tree_node *it = NULL;
> + unsigned long next = start;
> unsigned long serial = 0;
>
> end--; /* interval ranges are inclusive, but invalidate range is exclusive */
> - while (start < end) {
> + while (next < end) {
> struct drm_i915_gem_object *obj;
>
> obj = NULL;
> spin_lock(&mn->lock);
> + if (mn->is_linear)
> + return invalidate_range__linear(mn, mm, start, end);
Too bad that on first overlapping object the whole process goes into
"slow mode". I wonder what would benchmarking say to that.
Perhaps we could still use interval tree but add another layer of
indirection where ranges would be merged for overlapping objects and
contain a linear list of them only there?
Tvrtko
next prev parent reply other threads:[~2014-07-10 12:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-10 9:21 [PATCH 1/2] drm/i915: Allow overlapping userptr objects Chris Wilson
2014-07-10 9:21 ` [PATCH 2/2] drm/i915: Serialise userptr gup with mmu-notifier Chris Wilson
2014-07-10 9:32 ` Chris Wilson
2014-07-10 12:30 ` Tvrtko Ursulin
2014-07-10 12:26 ` Tvrtko Ursulin [this message]
2014-07-10 12:40 ` [PATCH 1/2] drm/i915: Allow overlapping userptr objects Chris Wilson
2014-07-10 20:20 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2014-07-21 12:21 Chris Wilson
2014-07-23 13:23 ` Tvrtko Ursulin
2014-07-23 14:34 ` Daniel Vetter
2014-07-23 15:08 ` Tvrtko Ursulin
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=53BE868D.8080301@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=akash.goel@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.