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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox