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,
	Tvrtko Ursulin <tvrtko@ursulin.net>
Subject: Re: [RFC 4/4] drm/i915: Stop tracking execlists retired requests
Date: Mon, 11 Apr 2016 10:10:56 +0100	[thread overview]
Message-ID: <570B6A20.8040604@linux.intel.com> (raw)
In-Reply-To: <20160408145703.GB1787@nuc-i3427.alporthouse.com>


On 08/04/16 15:57, Chris Wilson wrote:
> On Fri, Apr 08, 2016 at 02:54:58PM +0100, Tvrtko Ursulin wrote:
>> @@ -615,11 +613,6 @@ static void execlists_context_queue(struct drm_i915_gem_request *request)
>>   	struct drm_i915_gem_request *cursor;
>>   	int num_elements = 0;
>>
>> -	if (request->ctx != request->i915->kernel_context)
>> -		intel_lr_context_pin(request->ctx, engine);
>> -
>> -	i915_gem_request_reference(request);
>> -
>>   	spin_lock_bh(&engine->execlist_lock);
>>
>>   	list_for_each_entry(cursor, &engine->execlist_queue, execlist_link)
>> @@ -636,11 +629,12 @@ static void execlists_context_queue(struct drm_i915_gem_request *request)
>>   		if (request->ctx == tail_req->ctx) {
>>   			WARN(tail_req->elsp_submitted != 0,
>>   				"More than 2 already-submitted reqs queued\n");
>> -			list_move_tail(&tail_req->execlist_link,
>> -				       &engine->execlist_retired_req_list);
>> +			list_del(&tail_req->execlist_link);
>> +			i915_gem_request_unreference(tail_req);
>>   		}
>>   	}
>>
>> +	i915_gem_request_reference(request);
>>   	list_add_tail(&request->execlist_link, &engine->execlist_queue);
>
> If you want to get truly radical, we do not need the ref on the request
> until it is submitted to hardware. (As the request cannot be retired
> until it has done so, it can leave the execlist_queue until we commit it
> to hw, or perform the cancel).

Don't know. It is simple and nice that reference is tied to presence on 
execlist_queue.

More importantly, the patch as presented has a flaw that it dereferences 
req->ctx from execlists_check_remove_request where the context pin may 
have disappeared already due context complete interrupts getting behind 
when coallescing.

I will need to cache ctx_id in the request I think. It is fine do to 
that since ctx id must be unique and stable for a request.

Maybe even I should pull in your patch which makes ctx ids stable and 
persistent aligned with context existence and not pin. Think I've seen 
something like that somewhere.

Regards,

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

  reply	other threads:[~2016-04-11  9:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-08 13:54 [RFC 0/4] Eliminating the execlist retired request queue Tvrtko Ursulin
2016-04-08 13:54 ` [RFC 1/4] drm/i915: Move releasing of the GEM request from free to retire/cancel Tvrtko Ursulin
2016-04-08 15:01   ` Chris Wilson
2016-04-11  9:19     ` Tvrtko Ursulin
2016-04-08 13:54 ` [RFC 2/4] drm/i915/guc: Keep the previous context pinned until the next one has been completed Tvrtko Ursulin
2016-04-08 14:37   ` Chris Wilson
2016-04-11  8:58     ` Tvrtko Ursulin
2016-04-08 13:54 ` [RFC 3/4] drm/i915: Use new i915_gem_object_pin_map for LRC Tvrtko Ursulin
2016-04-08 14:40   ` Chris Wilson
2016-04-11  9:05     ` Tvrtko Ursulin
2016-04-11  9:18       ` Chris Wilson
2016-04-08 13:54 ` [RFC 4/4] drm/i915: Stop tracking execlists retired requests Tvrtko Ursulin
2016-04-08 14:57   ` Chris Wilson
2016-04-11  9:10     ` Tvrtko Ursulin [this message]
2016-04-11  9:23       ` Chris Wilson
2016-04-11  9:26       ` Chris Wilson
2016-04-08 14:08 ` ✗ Fi.CI.BAT: failure for Eliminating the execlist retired request queue Patchwork
2016-04-09  8:03 ` [RFC 0/4] " Chris Wilson
2016-04-11  9:19   ` Tvrtko Ursulin
2016-04-11 10:20     ` 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=570B6A20.8040604@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=tvrtko@ursulin.net \
    /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.