From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] drm/i915: Prevent recursion by retiring requests when the ring is full Date: Thu, 6 Feb 2014 17:44:05 +0100 Message-ID: <20140206164405.GO17001@phenom.ffwll.local> References: <1390862587-26669-1-git-send-email-chris@chris-wilson.co.uk> <20140128111535.GV9454@intel.com> <20140128112541.GH2508@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by gabe.freedesktop.org (Postfix) with ESMTP id 894E4FB921 for ; Thu, 6 Feb 2014 08:44:11 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id c41so1016583eek.30 for ; Thu, 06 Feb 2014 08:44:09 -0800 (PST) Content-Disposition: inline In-Reply-To: <20140128112541.GH2508@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Chris Wilson , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Tue, Jan 28, 2014 at 11:25:41AM +0000, Chris Wilson wrote: > On Tue, Jan 28, 2014 at 01:15:35PM +0200, Ville Syrj=E4l=E4 wrote: > > On Mon, Jan 27, 2014 at 10:43:07PM +0000, Chris Wilson wrote: > > > As the VM do not track activity of objects and instead use a large > > > hammer to forcibly idle and evict all of their associated objects when > > > one is released, it is possible for that to cause a recursion when we > > > need to wait for free space on a ring and call retire requests. > > > (intel_ring_begin -> intel_ring_wait_request -> > > > i915_gem_retire_requests_ring -> i915_gem_context_free -> > > > i915_gem_evict_vm -> i915_gpu_idle -> intel_ring_begin etc) > > > = > > > In order to remove the requirement for calling retire-requests from > > > intel_ring_wait_request, we have to inline a couple of steps from > > > retiring requests, notably we have to record the position of the requ= est > > > we wait for and use that to update the available ring space. > > > = > > > Signed-off-by: Chris Wilson > > = > > Looks good to me. > > Reviewed-by: Ville Syrj=E4l=E4 > > = > > I do have a couple of questions about request->tail though. > > = > > We set it to -1 in intel_ring_wait_request(). Isn't that going to cause > > problems for i915_request_guilty()? > > = > > When not -1, request->tail points to just before the commands that > > .add_request() adds to the ring. So that means intel_ring_wait_request() > > might have to wait for one extra request, and I guess more importantly > > if the GPU hangs inside the .add_request() commands, we won't attribute > > the hang to the request in question. Was it designe to be that way, or > > is there a bug here? > = > Ah good questions. I completely forgot about the behaviour here when we > adjusted this for hangstats... > = > Setting it to -1 should not confuse the guilty search since that should > be done (or at least changed so that is) based on a completion search. > After making that change, we should be able to set request->tail back to > being just after the request. Also I think we are quite safe to drop the > manipulation of request->tail inside intel_ring_wait_request(). Queued for -next, thanks for the patch. -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch