[PATCH v4 0/4] Implement lazy unmapping for GEM VRAM buffers

[Gerd Hoffmann]

On Fri, Sep 06, 2019 at 02:20:52PM +0200, Thomas Zimmermann wrote:
> Generic fbdev emulation maps and unmaps the console BO for updating it's
> content from the shadow buffer. If this involves an actual mapping
> operation (instead of reusing an existing mapping), lots of debug messages
> may be printed, such as
> 
>   x86/PAT: Overlap at 0xd0000000-0xd1000000
>   x86/PAT: reserve_memtype added [mem 0xd0000000-0xd02fffff], track write-combining, req write-combining, ret write-combining
>   x86/PAT: free_memtype request [mem 0xd0000000-0xd02fffff]
> 
> as reported at [1]. Drivers using VRAM helpers may also see reduced
> performance as the mapping operations can create overhead.
> 
> In v3 and later of the patch set, this problem is being solved by lazily
> unmapping the buffer as suggested by Gerd. Unmapping with drm_gem_vram_kunmap()
> only changes a reference counter. VRAM helpers later perform the unmapping
> operation when TTM evicts the buffer object from its current location. If
> the buffer is never evicted, the existing mapping is reused by later calls
> to drm_gem_vram_kmap().
> 
> v4:
> 	* lock kmap with ttm_bo_reserve()
> 	* acquire lock only once for vmap()
> 	* warn about stale mappings during buffer cleanup
> v3:
>       	* implement lazy unmapping
> v2:
> 	* fixed comment typos
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2019-September/234308.html
> 
> Thomas Zimmermann (4):
>   drm/vram: Add kmap ref-counting to GEM VRAM objects
>   drm/vram: Acquire lock only once per call to vmap()/vunmap()
>   drm/vram: Add infrastructure for move_notify()
>   drm/vram: Implement lazy unmapping for GEM VRAM buffers

Reviewed-by: Gerd Hoffmann <kraxel at redhat.com>

cheers,
  Gerd