Quoting Matthew Auld (2020-07-20 11:34:10)
> On 15/07/2020 12:50, Chris Wilson wrote:
> > The GEM object is grossly overweight for the practicality of tracking
> > large numbers of individual pages, yet it is currently our only
> > abstraction for tracking DMA allocations. Since those allocations need
> > to be reserved upfront before an operation, and that we need to break
> > away from simple system memory, we need to ditch using plain struct page
> > wrappers.
> >
> > In the process, we drop the WC mapping as we ended up clflushing
> > everything anyway due to various issues across a wider range of
> > platforms. Though in a future step, we need to drop the kmap_atomic
> > approach which suggests we need to pre-map all the pages and keep them
> > mapped.
> >
> > v2: Verify our large scratch page is suitably DMA aligned; and manually
> > clear the scratch since we are allocating random struct pages.
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Matthew Auld <matthew.auld@xxxxxxxxx>
> > ---
>
> <snip>
>
> > -
> > -static struct page *vm_alloc_page(struct i915_address_space *vm, gfp_t gfp)
> > -{
> > - struct pagevec stack;
> > - struct page *page;
> > -
> > - if (I915_SELFTEST_ONLY(should_fail(&vm->fault_attr, 1)))
> > - i915_gem_shrink_all(vm->i915);
>
>
> I guess shrink_boom et al are now mostly irrelevant in this new scheme.
The failures now occur at a less precarious time, but we can copy the
should_fail across, maybe even add more injection sites.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
