All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx <intel-gfx@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock
Date: Sun, 06 Nov 2011 11:57:55 +0000	[thread overview]
Message-ID: <e0d58a$2479a3@orsmga002.jf.intel.com> (raw)
In-Reply-To: <1320579094-1605-1-git-send-email-daniel.vetter@ffwll.ch>

On Sun,  6 Nov 2011 12:31:34 +0100, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> We don't have any read in a fastpath that needs forcewake, so I've
> decided to not care much about overhead.
> 
> This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
> snb on recent kernels - something must have slightly changed the
> timings.

Almost there. You just haven't explained the rationale for *this* patch,
which is that hangcheck needs to acquire the forcewake in order to read
the registers and hangcheck must not take the struct_mutex (or else
deadlock with wait_request and a hung GPU).

So there is a choice here: introduce a new locking rule for forcewake,
or use the existing struct_mutex inside hangcheck and therefore drop the
mutex for wait_request. The first definitely feels safer than dropping
struct_mutex on waits, and I haven't thought of any tangible benefits
for doing so (other than concurrent clients might see an improvement).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2011-11-06 11:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-06  0:31 [PATCH 1/2] drm/i915: properly lock gt_fifo_count Daniel Vetter
2011-11-06  0:31 ` [PATCH 2/2] drm/i915: protect force_wake_(get|put) with the gt_lock Daniel Vetter
2011-11-06  0:41 ` [PATCH 1/2] drm/i915: properly lock gt_fifo_count Daniel Vetter
2011-11-06  8:39   ` Chris Wilson
2011-11-06 10:46     ` Daniel Vetter
2011-11-06 11:31       ` [PATCH] drm/i915: protect force_wake_(get|put) with the gt_lock Daniel Vetter
2011-11-06 11:57         ` Chris Wilson [this message]
2011-11-06 12:35           ` Daniel Vetter
2011-11-06 21:01             ` Chris Wilson
2011-11-06 22:06               ` Daniel Vetter
  -- strict thread matches above, loose matches on Subject: below --
2011-11-06 17:42 Nicolas Kalkhof
2011-11-06 17:46 ` Daniel Vetter
2011-11-07 13:52 Nicolas Kalkhof
2011-11-07 16:05 ` Daniel Vetter
2011-11-07 16:39 Nicolas Kalkhof
2011-11-07 16:56 ` Daniel Vetter
2011-11-07 17:31 Nicolas Kalkhof
2011-11-07 18:14 Nicolas Kalkhof
2011-11-07 18:36 ` Daniel Vetter
2011-11-09 16:22 Nicolas Kalkhof
2011-11-09 16:28 ` Daniel Vetter

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='e0d58a$2479a3@orsmga002.jf.intel.com' \
    --to=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.