[Intel-gfx] [PATCH 2/3] drm/i915/gtt: Free unused lower-level page tables

[Chris Wilson]

On Wed, Oct 05, 2016 at 09:40:48AM +0300, Joonas Lahtinen wrote:
> On ti, 2016-10-04 at 15:54 +0200, Michał Winiarski wrote:
> > Since "Dynamic page table allocations" were introduced, our page tables
> > can grow (being dynamically allocated) with address space range usage.
> > Unfortunately, their lifetime is bound to vm. This is not a huge problem
> > when we're not using softpin - drm_mm is creating an upper bound on used
> > range by causing addresses for our VMAs to eventually be reused.
> > 
> > With softpin, long lived contexts can drain the system out of memory
> > even with a single "small" object. For example:
> > 
> > bo = bo_alloc(size);
> > while(true)
> >     offset += size;
> >     exec(bo, offset);
> > 
> > Will cause us to create new allocations until all memory in the system
> > is used for tracking GPU pages (even though almost all PTEs in this vm
> > are pointing to scratch).
> > 
> > Let's free unused page tables in clear_range to prevent this - if no
> > entries are used, we can safely free it and return this information to
> > the caller (so that higher-level entry is pointing to scratch).
> > 
> 
> Sounds like this could and should have a I-G-T testcase, right?

The problem is that tables are internal to the driver. The user visible
impact is premature oom due to kernel bloat. We could dump the ppgtt to
userpsace and assert that entries we have closed are unused, but that
would be a fragile test for one particular implementation.

gem_exec_alignment will oom quite happily at the moment due to the
bitmap allocation (once we have the u64 alignment fixes reviewed and
upsteamed at least). Simply for that reason I want to completely
erradicate the bitmaps - they are not used for anything. The valid
range intersection we already know, and here the use as to whether a
particular level is empty is a simple counter.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre