From: Daniel Vetter <daniel@ffwll.ch>
To: David Rientjes <rientjes@google.com>
Cc: Rob Clark <robdclark@gmail.com>,
sanjeev sharma <sanjeevsharmaengg@gmail.com>,
Guenter Roeck <linux@roeck-us.net>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm: Do not use BUG_ON(!spin_is_locked())
Date: Tue, 12 Aug 2014 08:55:16 +0200 [thread overview]
Message-ID: <20140812065516.GI10500@phenom.ffwll.local> (raw)
In-Reply-To: <alpine.DEB.2.02.1408111636370.23479@chino.kir.corp.google.com>
On Mon, Aug 11, 2014 at 04:38:50PM -0700, David Rientjes wrote:
> On Mon, 11 Aug 2014, Rob Clark wrote:
>
> > > I'm suggesting that if you don't want to incur the cost of the conditional
> > > everytime you call a certain function with assert_spin_locked() that you
> > > could covert these to lockdep_assert_held() so the check is only done when
> > > lockdep is enabled for debugging.
> >
> > not sure about the nouveau parts, but for the omap and msm hunks, this
> > code getting called at potentially vblank rate (so maybe once or twice
> > per ~16ms).. and lockdep has considerable overhead (for a gpu driver)
> > so I don't always have it enabled. So it sounds like for those two at
> > least assert_spin_locked() is a better option.
> >
>
> Unless there's a bug, assert_spin_locked() is just going to incur an
> unnecessary cost every time it is called at runtime. My suggestion was to
> limit that check only to debugging kernels that include enabling lockdep
> when tracking down problems rather than needlessly evaluating the
> conditional every time when there are no bugs.
My experience with gpu drivers (i915) has been that hw and the software
running it is varied enough that almost always it's better to
unconditionally enable this stuff. I much prefer assert_spin_locked and
friends over the lockdep versions since enabling full lockdep is not
something you usually do. Especially not normal users, and we rely upon
them for testing the old stuff. Furthermore for the modeset code the
overhead is totally irrelevant since we're doing metric piles of register
reads and writes in there anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-08-12 6:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 4:31 [PATCH] drm: Do not use BUG_ON(!spin_is_locked()) Guenter Roeck
2014-08-11 11:45 ` David Rientjes
2014-08-11 14:06 ` Guenter Roeck
[not found] ` <CAGUYZuS=_rFpukssRebxXBccPrJAen15i8Qf3K+1YyF+feShdQ@mail.gmail.com>
[not found] ` <CAGUYZuSk4u5jyPcrYTjwjXmQRyr0kCEvxkgFfjcyP+ex544CLA@mail.gmail.com>
2014-08-11 20:53 ` David Rientjes
2014-08-11 23:09 ` Rob Clark
2014-08-11 23:38 ` David Rientjes
2014-08-12 6:55 ` Daniel Vetter [this message]
[not found] ` <CAGUYZuRwKXyRuYg1xDB9u1gE4gTRcpV_c_O645N8V-yksSfsNQ@mail.gmail.com>
2014-09-01 6:18 ` Dave Airlie
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=20140812065516.GI10500@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=rientjes@google.com \
--cc=robdclark@gmail.com \
--cc=sanjeevsharmaengg@gmail.com \
/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