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

[Daniel Vetter]

On Wed, Aug 7, 2013 at 1:25 AM, Ben Widawsky <ben at bwidawsk.net> 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 at bwidawsk.net> 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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch