On Tue, Jan 12, 2021 at 10:47:57AM +0000, Matthew Auld wrote: > On Fri, 27 Nov 2020 at 13:32, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
