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@xxxxxxxxxxxxxxxxxx> > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
