[Intel-gfx] [PATCH] drm/i915: Replace racy object bookkeeping

[Daniel Vetter]

On Wed, Jul 24, 2013 at 10:20:43AM +0100, Chris Wilson wrote:
> On Wed, Jul 24, 2013 at 10:48:49AM +0200, Daniel Vetter wrote:
> > On Sun, Jul 21, 2013 at 01:18:05PM +0200, Daniel Vetter wrote:
> > > On Sun, Jul 21, 2013 at 09:57:04AM +0100, Chris Wilson wrote:
> > > > Now that we track objects for their entire lifetime in a list, we can
> > > > move the cost of the bookkeeping to the infrequent query of
> > > > i915_gem_objects. This also removes the race where we would increment the
> > > > global object count and size without holding any locks.
> > > > 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67121
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > 
> > > I love it when I can check off items from my todo list simply by merging a
> > > patch ;-) Queued for -next, thanks for the patch.
> > 
> > This now omits allocated objects for which obj->pages is NULL, so we'd
> > miss some classes of leaks. So I've dropped this patch again, I guess we
> > should add spinlock or something. Or use and atomic_t and just count
> > objects.
> 
> I'd rather have consistent underreporting than garbage though. I think
> this patch is the lesser of two evils... And you can propose adding a
> lock/locked operation to open.

I'd like to have a fully reliable object count though since that should be
useful for writing leak testcases. kmemleak isn't that reliable
unfortunately. Looking at the debugfs stuff we already report
bound+unbound (just separate) so I don't think this patch adds useful
information.

Let me play around with broken igts a bit more, I'll send in a patch to
make this solid if it's indeed useful.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch