From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Mika Kuoppala <mika.kuoppala@linux.intel.com>,
intel-gfx@lists.freedesktop.org, miku@iki.fi
Subject: Re: [PATCH 2/2] drm/i915: Protect engine request list with spinlock
Date: Tue, 24 Feb 2015 00:58:19 +0100 [thread overview]
Message-ID: <20150223235819.GG24485@phenom.ffwll.local> (raw)
In-Reply-To: <20150219164112.GA16922@nuc-i3427.alporthouse.com>
On Thu, Feb 19, 2015 at 04:41:12PM +0000, Chris Wilson wrote:
> On Thu, Feb 19, 2015 at 06:18:55PM +0200, Mika Kuoppala wrote:
> > There are multiple players interested in the ring->request_list
> > state. Request submission can happen in kernel or user context,
> > idle worker is going through request list to free items. And then there
> > is hangcheck worker which tries to figure out if particular ring is
> > healthy by peeking at the request list among other things. And if
> > judged stuck by hangcheck, error state is colleted. Which in turns
> > needs access to ring->request_list.
>
> We have discussed this before. Hangcheck does not need the lock so long
> as it is serialised with deletion. List processing with hangcheck during
> concurrent addition is safe.
>
> For example, I expect the request locking to look like
>
> http://cgit.freedesktop.org/~ickle/linux-2.6/tree/drivers/gpu/drm/i915/i915_gem_request.c#n691
I think longer-term with per-engine reset and fun stuff like that we
probably want the spinlock, just to avoid too many headaches with locking
auditing. For the execbuf fastpath it should just be one more spinlock per
ioctl, so hopefully bearable.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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-02-23 23:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 16:18 [PATCH 1/2] drm/i915: Split adding request to smaller functions Mika Kuoppala
2015-02-19 16:18 ` [PATCH 2/2] drm/i915: Protect engine request list with spinlock Mika Kuoppala
2015-02-19 16:41 ` Chris Wilson
2015-02-23 23:58 ` Daniel Vetter [this message]
2015-02-24 8:31 ` Chris Wilson
2015-02-24 10:39 ` Daniel Vetter
2015-02-24 10:52 ` Chris Wilson
2015-02-24 11:23 ` Mika Kuoppala
2015-02-24 11:40 ` Chris Wilson
2015-02-24 12:57 ` Daniel Vetter
2015-02-19 16:54 ` [PATCH 1/2] drm/i915: Split adding request to smaller functions John Harrison
2015-02-20 9:16 ` Mika Kuoppala
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=20150223235819.GG24485@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mika.kuoppala@linux.intel.com \
--cc=miku@iki.fi \
/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