Re: [PATCH 18/29] drm/i915: Use new bind/unbind in eviction code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 06, 2013 at 02:27:39PM -0700, Ben Widawsky wrote:
> On Tue, Aug 06, 2013 at 08:39:50PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 31, 2013 at 05:00:11PM -0700, Ben Widawsky wrote:
> > > @@ -183,9 +186,11 @@ i915_gem_evict_everything(struct drm_device *dev)
> > >  	i915_gem_retire_requests(dev);
> > >  
> > >  	/* Having flushed everything, unbind() should never raise an error */
> > > -	list_for_each_entry_safe(obj, next, &vm->inactive_list, mm_list)
> > > -		if (obj->pin_count == 0)
> > > -			WARN_ON(i915_gem_object_ggtt_unbind(obj));
> > > +	list_for_each_entry(vm, &dev_priv->vm_list, global_link) {
> > > +		list_for_each_entry_safe(obj, next, &vm->inactive_list, mm_list)
> > > +			if (obj->pin_count == 0)
> > > +				WARN_ON(i915_vma_unbind(i915_gem_obj_to_vma(obj, vm)));
> > > +	}
> > 
> > The conversion of evict_everything looks a bit strange. Essentially we
> > have tree callers:
> > - ums+gem support code in leavevt to rid the gtt of all gem objects when
> >   the userspace X ums ddx stops controlling the hw.
> > - When we seriously ran out of memory in, shrink_all.
> > - In execbuf when we've fragmented the gtt address space so badly that we
> >   need to start over completely fresh.
> > 
> > With this it imo would make sense to just loop over the global bound
> > object lists. But for the execbuf caller adding a vm parameter (and only
> > evicting from that special vm, skipping all others) would make sense.
> > Other callers would pass NULL since they want everything to get evicted.
> > Volunteered for that follow-up?
> > 
> 
> We need evict_everything for #1. For #2, we call evict_something already
> for the vm when we go through the out of space path. If that failed,
> evicting everything for a specific VM is just the same operation. But
> maybe I've glossed over something in the details. Please correct if I'm
> wrong. Is there a case where evict something might fail with ENOSPC, and
> evict everything in a VM would help?

Yes, when we've terminally fragmented the gtt we kick out everything and
start over. That's the 3rd usecase.
-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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux