From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH 18/29] drm/i915: Use new bind/unbind in
 eviction code
Date: Wed, 7 Aug 2013 11:24:14 -0700
Message-ID: <20130807182414.GB975@bwidawsk.net>
References: <1375315222-4785-1-git-send-email-ben@bwidawsk.net>
	<1375315222-4785-19-git-send-email-ben@bwidawsk.net>
	<20130806183950.GC22035@phenom.ffwll.local>
	<20130806212738.GA2462@bwidawsk.net>
	<20130806212949.GO22035@phenom.ffwll.local>
	<20130806225711.GC2462@bwidawsk.net>
	<CAKMK7uHA6LFVYpVdeBS1_kycSy=xqSxHQtMAdsfWMYv06R4hbA@mail.gmail.com>
	<20130806232533.GA18216@bwidawsk.net>
	<CAKMK7uFEZY1nge2et+aw1mN7Z3fQuGtpQPupYXH2_zU_M82VUQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mail.bwidawsk.net (bwidawsk.net [166.78.191.112])
	by gabe.freedesktop.org (Postfix) with ESMTP id 7ACC3E5BF7
	for <intel-gfx@lists.freedesktop.org>;
	Wed,  7 Aug 2013 11:24:29 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <CAKMK7uFEZY1nge2et+aw1mN7Z3fQuGtpQPupYXH2_zU_M82VUQ@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

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@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@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

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