This is a golden oldie! We can shave a couple of locked instructions for about 10% of the per-object overhead by not taking an extra kref whilst reserving objects for an execbuf. Due to lock management this is safe, as we cannot lose the original object reference without the lock. Equally, because this relies on the heavy BKL^W struct_mutex, it is also likely to be only a temporary optimisation until we have fine grained locking. (That's what we said 5 years ago!) Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 734a7ef56a93..1b673c55934e 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -142,7 +142,6 @@ eb_lookup_vmas(struct eb_vmas *eb, goto err; } - drm_gem_object_reference(&obj->base); list_add_tail(&obj->obj_exec_link, &objects); } spin_unlock(&file->table_lock); @@ -260,7 +259,6 @@ static void eb_destroy(struct eb_vmas *eb) exec_list); list_del_init(&vma->exec_list); i915_gem_execbuffer_unreserve_vma(vma); - drm_gem_object_unreference(&vma->obj->base); } kfree(eb); } @@ -873,7 +871,6 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev, vma = list_first_entry(&eb->vmas, struct i915_vma, exec_list); list_del_init(&vma->exec_list); i915_gem_execbuffer_unreserve_vma(vma); - drm_gem_object_unreference(&vma->obj->base); } mutex_unlock(&dev->struct_mutex); -- 2.1.4 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
