[Intel-gfx] [RFC PATCH 098/162] drm/i915/gtt: map the PD up front

[Daniel Vetter]

On Tue, Jan 12, 2021 at 10:47:57AM +0000, Matthew Auld wrote:
> On Fri, 27 Nov 2020 at 13:32, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >
> > Quoting Matthew Auld (2020-11-27 12:06:14)
> > > We need to general our accessor for the page directories and tables from
> > > using the simple kmap_atomic to support local memory, and this setup
> > > must be done on acquisition of the backing storage prior to entering
> > > fence execution contexts. Here we replace the kmap with the object
> > > maping code that for simple single page shmemfs object will return a
> > > plain kmap, that is then kept for the lifetime of the page directory.
> > >
> > > Signed-off-by: Matthew Auld <matthew.auld at intel.com>
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >
> > We are going to really struggle with this on 32b :(
> 
> Just go back to mapping everything on demand like we did previously,
> and unmap as soon as we are done with the current directory across
> alloc/insert/clear?

tbh if you run i915.ko on 32b kernels, on a modern platform, you deserve
all the pain you get. There's quite a bit of work going on to essentially
make kmap functions worse on 32b (we're not yet at the stage where people
propose to nuke them, but getting there slowly), so designing code today
with them in mind as primary justification is backwards.

What we can't do is keep kmap around forever, it'd need to be something
like vmap that has a long-term mapping intention behind it. And at that
point it's probably equally amounts of work to just go back to ad-hoc
kmap. Also the rules have changed somewhat with kmap_local anyway, a kmap
is a lot less painful in the code than it was with kmap_atomic.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch