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@xxxxxxxxx wrote: > > From: Rafael Barbalho <rafael.barbalho@xxxxxxxxx> > > > > 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@xxxxxxxxx> > > Cc: Daniel Vetter <daniel@xxxxxxxx> > > Cc: Jon Bloomfield <jon.bloomfield@xxxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
