Re: [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand

From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Daniel <thomas.daniel@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand
Date: Mon, 24 Nov 2014 15:24:32 +0100	[thread overview]
Message-ID: <20141124142432.GS25711@phenom.ffwll.local> (raw)
In-Reply-To: <1415874490-386-1-git-send-email-thomas.daniel@intel.com>

On Thu, Nov 13, 2014 at 10:28:10AM +0000, Thomas Daniel wrote:
> From: Oscar Mateo <oscar.mateo@intel.com>
> 
> Up until now, we have pinned every logical ring context backing object
> during creation, and left it pinned until destruction. This made my life
> easier, but it's a harmful thing to do, because we cause fragmentation
> of the GGTT (and, eventually, we would run out of space).
> 
> This patch makes the pinning on-demand: the backing objects of the two
> contexts that are written to the ELSP are pinned right before submission
> and unpinned once the hardware is done with them. The only context that
> is still pinned regardless is the global default one, so that the HWS can
> still be accessed in the same way (ring->status_page).
> 
> v2: In the early version of this patch, we were pinning the context as
> we put it into the ELSP: on the one hand, this is very efficient because
> only a maximum two contexts are pinned at any given time, but on the other
> hand, we cannot really pin in interrupt time :(
> 
> v3: Use a mutex rather than atomic_t to protect pin count to avoid races.
> Do not unpin default context in free_request.
> 
> v4: Break out pin and unpin into functions.  Fix style problems reported
> by checkpatch
> 
> v5: Remove unpin_lock as all pinning and unpinning is done with the struct
> mutex already locked.  Add WARN_ONs to make sure this is the case in future.
> 
> Issue: VIZ-4277
> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>

This patch here scored a regression (leak in the module unload path),
please address it asap. Deadline for regressions should be 1 week, then
I'll just drop the patch or apply the revert. That includes review and
everything.

https://bugs.freedesktop.org/show_bug.cgi?id=86507

Thanks,
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx