[Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction

[Chris Wilson]

On Fri, Feb 13, 2015 at 10:51:36AM +0100, Daniel Vetter wrote:
> On Thu, Feb 12, 2015 at 08:05:02PM +0000, rafael.barbalho at intel.com wrote:
> > From: Rafael Barbalho <rafael.barbalho at intel.com>
> > 
> > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be
> > cleaned up so that the PPGTT PDE & PTE allocations can be freed.
> > 
> > This problem only shows up with full PPGTT because an object's VMA is
> > only cleaned-up when the object is destroyed. However, if the object has
> > been shared between multiple processes this may not happen, which leads to
> > references to the PPGTT still being kept the object was shared.
> > 
> > Under android the sharing of GEM objects is a fairly common operation, thus
> > the clean-up has to be more agressive.
> > 
> > Signed-off-by: Rafael Barbalho <rafael.barbalho at intel.com>
> > Cc: Daniel Vetter <daniel at ffwll.ch>
> > Cc: Jon Bloomfield <jon.bloomfield at intel.com>
> 
> So when we've merged this we iirc talked about this issue and decided that
> the shrinker should be good enough in cleaning up the crap from shared
> objects. Not a pretty solution, but it should have worked.
> 
> Is this again the lowmemory killer wreaking havoc with our i915 shrinker,
> or is there something else going on? And do you have some igt testcase for
> this? If sharing is all that's required the following should do the trick:
> 1. allocate obj
> 2. create new context
> 3. do dummy execbuf with that obj to map it into the ppgtt
> 4. free context
> 5. goto 2 often enough to OOM

You know I have patches to fix all of this... It just happens to fall
out of tracking vma in requests, and by extension vm.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre