public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 1/3] drm/i915: Only update the current userptr worker
Date: Wed, 9 Sep 2015 11:39:01 +0100	[thread overview]
Message-ID: <55F00C45.4010209@linux.intel.com> (raw)
In-Reply-To: <1439196700-20045-1-git-send-email-chris@chris-wilson.co.uk>


On 08/10/2015 09:51 AM, Chris Wilson wrote:
> The userptr worker allows for a slight race condition where upon there
> may two or more threads calling get_user_pages for the same object. When
> we have the array of pages, then we serialise the update of the object.
> However, the worker should only overwrite the obj->userptr.work pointer
> if and only if it is the active one. Currently we clear it for a
> secondary worker with the effect that we may rarely force a second
> lookup.

v2 changelog?

> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/i915_gem_userptr.c | 32 ++++++++++++++++----------------
>   1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index d11901d590ac..800a5394aa1e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -571,25 +571,25 @@ __i915_gem_userptr_get_pages_worker(struct work_struct *_work)
>   	struct get_pages_work *work = container_of(_work, typeof(*work), work);
>   	struct drm_i915_gem_object *obj = work->obj;
>   	struct drm_device *dev = obj->base.dev;
> -	const int num_pages = obj->base.size >> PAGE_SHIFT;
> +	const int npages = obj->base.size >> PAGE_SHIFT;
>   	struct page **pvec;
>   	int pinned, ret;
>
>   	ret = -ENOMEM;
>   	pinned = 0;
>
> -	pvec = kmalloc(num_pages*sizeof(struct page *),
> +	pvec = kmalloc(npages*sizeof(struct page *),
>   		       GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
>   	if (pvec == NULL)
> -		pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
> +		pvec = drm_malloc_ab(npages, sizeof(struct page *));
>   	if (pvec != NULL) {
>   		struct mm_struct *mm = obj->userptr.mm->mm;
>
>   		down_read(&mm->mmap_sem);
> -		while (pinned < num_pages) {
> +		while (pinned < npages) {
>   			ret = get_user_pages(work->task, mm,
>   					     obj->userptr.ptr + pinned * PAGE_SIZE,
> -					     num_pages - pinned,
> +					     npages - pinned,

If you hadn't done this renaming you could have gotten away without a v2 
changelog request... :)

>   					     !obj->userptr.read_only, 0,
>   					     pvec + pinned, NULL);
>   			if (ret < 0)
> @@ -601,20 +601,20 @@ __i915_gem_userptr_get_pages_worker(struct work_struct *_work)
>   	}
>
>   	mutex_lock(&dev->struct_mutex);
> -	if (obj->userptr.work != &work->work) {
> -		ret = 0;
> -	} else if (pinned == num_pages) {
> -		ret = __i915_gem_userptr_set_pages(obj, pvec, num_pages);
> -		if (ret == 0) {
> -			list_add_tail(&obj->global_list, &to_i915(dev)->mm.unbound_list);
> -			obj->get_page.sg = obj->pages->sgl;
> -			obj->get_page.last = 0;
> -
> -			pinned = 0;
> +	if (obj->userptr.work == &work->work) {
> +		if (pinned == npages) {
> +			ret = __i915_gem_userptr_set_pages(obj, pvec, npages);
> +			if (ret == 0) {
> +				list_add_tail(&obj->global_list,
> +					      &to_i915(dev)->mm.unbound_list);
> +				obj->get_page.sg = obj->pages->sgl;
> +				obj->get_page.last = 0;

Wouldn't obj->get_page init fit better into 
__i915_gem_userptr_set_pages? Although that code is not from this patch. 
How come it is OK not to initialize them in the non-worker case?

With the v2 changelog, or dropped rename:

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2015-09-09 10:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-10  8:51 [PATCH v3 1/3] drm/i915: Only update the current userptr worker Chris Wilson
2015-08-10  8:51 ` [PATCH v3 2/3] drm/i915: Fix userptr deadlock with aliased GTT mmappings Chris Wilson
2015-09-09 13:56   ` [Intel-gfx] " Tvrtko Ursulin
2015-09-09 15:03     ` Chris Wilson
2015-09-10  9:44       ` [Intel-gfx] " Tvrtko Ursulin
2015-09-10  9:51         ` Chris Wilson
2015-08-10  8:51 ` [PATCH v3 3/3] drm/i915: Use a task to cancel the userptr on invalidate_range Chris Wilson
2015-09-09 14:45   ` Tvrtko Ursulin
2015-09-09 15:08     ` Chris Wilson
2015-09-09 15:20       ` Tvrtko Ursulin
2015-09-09 15:42         ` Chris Wilson
2015-09-10  9:50           ` Tvrtko Ursulin
2015-09-09 10:39 ` Tvrtko Ursulin [this message]
2015-09-09 10:44   ` [PATCH v3 1/3] drm/i915: Only update the current userptr worker Chris Wilson

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=55F00C45.4010209@linux.intel.com \
    --to=tvrtko.ursulin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox