All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	intel-gfx@lists.freedesktop.org,
	John Harrison <John.C.Harrison@Intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm/i915: Keep ring->active_list and ring->requests_list consistent
Date: Fri, 20 Mar 2015 16:33:08 +0100	[thread overview]
Message-ID: <20150320153308.GV1349@phenom.ffwll.local> (raw)
In-Reply-To: <20150320150439.GA23241@nuc-i3427.alporthouse.com>

On Fri, Mar 20, 2015 at 03:04:39PM +0000, Chris Wilson wrote:
> On Fri, Mar 20, 2015 at 04:00:50PM +0100, Daniel Vetter wrote:
> > On Fri, Mar 20, 2015 at 02:45:04PM +0000, Chris Wilson wrote:
> > > On Fri, Mar 20, 2015 at 03:32:52PM +0100, Daniel Vetter wrote:
> > > > But if we do that short-circuiting in ring_idle the all the requests
> > > > _should_ be completed. Which meanse retire_request_ring should move all
> > > > buffers to the inactive list, even when we do that before retiring
> > > > requests.
> > > 
> > > We test for the requests to be retired after we test for the buffers to
> > > be retired. It is very easy then for us to have active buffers as the
> > > seqno advanced after the buffer retirement and before the requests. That
> > > is (one of) the reasons why we previously sampled seqno only once when
> > > retiring buffers + requests.
> > 
> > Yeah I get that part of the race. But before we retire anything in these
> > callsites we call gpu_idle. And that waits for everything to complete,
> > except whent there are not outstanding requests (i.e. ->request_list is
> > empyt). So either
> > - ->request_list is empty in ring_idle, which means all requests should
> >   have completed.  Even if there are some lingering active buffers still
> >   around we should clean them up.
> > - ->request_list is not empty, in which case we do a full wait for the
> >   most recent request. Again all requests should have completed and we
> >   should be able to clean out both request and active lists.
> > 
> > I do see how we can get out of the retire_request functions with requests
> > empty but still active buffers around. But I don't understand how that's
> > possible with a gpu_idle in front. And thus far all traces are from places
> > where we do call gpu_idle first.
> > 
> > Or am I missing something?
> 
> The retire comes before the before the gpu_idle (we retire often as a
> part of busy, execbuffer, timers etc). The traces show exactly that.

Yeah, the sequence I see is:
1. retire requests leaves active objects behind with all requests retired.
2. evict_vim
|-> 2a. gpu_idle
|-> 2b. retire_requests
|-> 2c. WARN_ON(i915_gem_evict_vm);

I agree with you that before the call to evict_vm the lists are
inconsistent. What I don't understand how that inconsistency can get past
the 2a/2b double-punch.

Or do I have the wrong sequence in mind?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-03-20 15:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18 18:19 [PATCH] drm/i915: Keep ring->active_list and ring->requests_list consistent Chris Wilson
2015-03-19 11:18 ` shuang.he
2015-03-19 17:37 ` Daniel Vetter
2015-03-19 22:17   ` Chris Wilson
2015-03-20 10:06     ` Daniel Vetter
2015-03-20 13:02       ` Chris Wilson
2015-03-20 13:39         ` Chris Wilson
2015-03-20 14:32           ` Daniel Vetter
2015-03-20 14:45             ` Chris Wilson
2015-03-20 15:00               ` Daniel Vetter
2015-03-20 15:04                 ` Chris Wilson
2015-03-20 15:33                   ` Daniel Vetter [this message]
2015-03-20 15:36                     ` Chris Wilson
2015-03-23  8:43                       ` Daniel Vetter
2015-03-23  8:49 ` Daniel Vetter
2015-03-23  9:13   ` Chris Wilson
2015-03-23  9:15     ` Chris Wilson
2015-03-23  9:40       ` Daniel Vetter
2015-03-25 11:43   ` Jani Nikula

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=20150320153308.GV1349@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=John.C.Harrison@Intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --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.