yes you are absolutely correct and the change I have done in other area i.e drivers/usb/storage/uas.c.In gpu drivers assert_spin_locked() make more sense.
Regards Sanjeev Sharma On Tue, Aug 12, 2014 at 12:25 PM, Daniel Vetter <daniel at ffwll.ch> wrote: > 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 part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/55b29765/attachment.html>