On Wed, Aug 07, 2013 at 01:44:58AM +0200, Daniel Vetter wrote: > On Wed, Aug 7, 2013 at 1:25 AM, Ben Widawsky <ben@xxxxxxxxxxxx> wrote: > > On Wed, Aug 07, 2013 at 12:59:29AM +0200, Daniel Vetter wrote: > >> On Wed, Aug 7, 2013 at 12:57 AM, Ben Widawsky <ben@xxxxxxxxxxxx> wrote: > >> >> > 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. > >> > > >> > I am not seeing it. To me evict_something is what you want, and the fix > >> > for wherever the 3rd usecase is (please point it out, I'm dense) is it > >> > should call evict_something, not evict_everything. > >> > >> See the call to evict_everything in > >> i915_gem_execbuffer.c:i915_gem_execbuffer_reserve > >> > > > > As I was saying in the first response - you only hit this if > > evict_something() for a vm fails, right? That's the way ret == ENOSPC > > AFAICT. > > Like I've said if we can't fit a batch we do a last ditch effort of > evicting everything and starting over anew. That's also what the retry > logic in there is for. This happens after evict_something failed. > Dunno what exactly isn't clear or what's confusing ... > -Daniel Okay, sorted this out on IRC. You'll get a new patch as described with a new function for per vm eviction (which will just idle, and call evict_something() with proper args) -- Ben Widawsky, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
