All of lore.kernel.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: 16+ 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-09 15:03       ` [Intel-gfx] " Chris Wilson
2015-09-10  9:44       ` Tvrtko Ursulin
2015-09-10  9:51         ` Chris Wilson
2015-09-10  9:51           ` [Intel-gfx] " 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 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.