Re: [PATCH v5] drm/i915: Cache LRC state page in the context

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 15, 2016 at 04:39:29PM +0000, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> 
> LRC lifetime is well defined so we can cache the page pointing
> to the object backing store in the context in order to avoid
> walking over the object SG page list from the interrupt context
> without the big lock held.
> 
> v2: Also cache the mapping. (Chris Wilson)
> v3: Unmap on the error path.
> v4: No need to cache the page. (Chris Wilson)
> v5: No need to dirty the page on unpin. (Chris Wilson)

Sorry.

> @@ -1076,12 +1069,25 @@ static int intel_lr_context_do_pin(struct intel_engine_cs *ring,
>  	if (ret)
>  		return ret;
>  
> +	lrc_state_page = i915_gem_object_get_dirty_page(ctx_obj, LRC_STATE_PN);
> +	if (WARN_ON(!lrc_state_page)) {
> +		ret = -ENODEV;
> +		goto unpin_ctx_obj;
> +	}
> +
> +	lrc_reg_state = kmap(lrc_state_page);

kmap() cannot fail.

> +	if (!lrc_reg_state) {
> +		ret = -ENOMEM;
> +		goto unpin_ctx_obj;
> +	}
> +	if (--rq->ctx->engine[ring->id].pin_count == 0) {

I was wondering if we should just use

kunmap(kmap_to_page(ce->lrc_reg_state));

Except until we get struct intel_context_engine that line will exceed
80cols!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux