[Intel-gfx] [PATCH 5/7] drm/i915: Preallocate stashes for vma page-directories

[Chris Wilson]

Quoting Matthew Auld (2020-07-10 18:48:31)
> On Wed, 8 Jul 2020 at 14:48, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >
> > We need to make the DMA allocations used for page directories to be
> > performed up front so that we can include those allocations in our
> > memory reservation pass. The downside is that we have to assume the
> > worst case, even before we know the final layout, and always allocate
> > enough page directories for this object, even when there will be overlap.
> > This unfortunately can be quite expensive, especially as we have to
> > clear/reset the page directories and DMA pages, but it should only be
> > required during early phases of a workload when new objects are being
> > discovered, or after memory/eviction pressure when we need to rebind.
> > Once we reach steady state, the objects should not be moved and we no
> > longer need to preallocating the pages tables.
> >
> > It should be noted that the lifetime for the page directories DMA is
> > more or less decoupled from individual fences as they will be shared
> > across objects across timelines.
> >
> > v2: Only allocate enough PD space for the PTE we may use, we do not need
> > to allocate PD that will be left as scratch.
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Matthew Auld <matthew.auld at intel.com>
> 
> <snip>
> 
> >
> > +static unsigned long pd_count(u64 size, int shift)
> > +{
> > +       /* Beware later misalignment */
> > +       return (size + 2 * (BIT_ULL(shift) - 1)) >> shift;
> > +}
> > +
> > +int i915_vm_alloc_pt_stash(struct i915_address_space *vm,
> > +                          struct i915_vm_pt_stash *stash,
> > +                          u64 size)
> > +{
> > +       unsigned long count;
> > +       int shift = 21;
> > +       int n;
> 
> if (gen >= 8)
>     shift = 21;
> else
>     shift = 22;
> 
> ?
> 
> Since pt=4M, pd=2G with the weird legacy ppgtt stuff?

I thought about it, but it just means we overallocate, and promptly free
again. That's not a huge issue for the single setup we do with the
aliasing-ppgtt, so I was waiting to see if there would be anything else to
spoil the simplicity of the levels. 128b address spaces anytime soon?

When the dust settled I was thinking more along the lines of
vm->pte_count? pte_width, maxptes, pte_shift?
-Chris