| Message ID | 20190906122056.32018-1-tzimmermann@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | Implement lazy unmapping for GEM VRAM buffers | expand |
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 On the series: Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> -Daniel > > 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 > > drivers/gpu/drm/drm_gem_vram_helper.c | 229 ++++++++++++++++++-------- > drivers/gpu/drm/drm_vram_mm_helper.c | 12 ++ > include/drm/drm_gem_vram_helper.h | 18 ++ > include/drm/drm_vram_mm_helper.h | 4 + > 4 files changed, 198 insertions(+), 65 deletions(-) > > -- > 2.23.0 >
On Fri, 06 Sep 2019, 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 > > drivers/gpu/drm/drm_gem_vram_helper.c | 229 ++++++++++++++++++-------- > drivers/gpu/drm/drm_vram_mm_helper.c | 12 ++ > include/drm/drm_gem_vram_helper.h | 18 ++ > include/drm/drm_vram_mm_helper.h | 4 + > 4 files changed, 198 insertions(+), 65 deletions(-) Thanks for the prompt fix, feel free to add my: Reported-and-tested-by: Davidlohr Bueso <dbueso@suse.de>
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@redhat.com> cheers, Gerd
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 drivers/gpu/drm/drm_gem_vram_helper.c | 229 ++++++++++++++++++-------- drivers/gpu/drm/drm_vram_mm_helper.c | 12 ++ include/drm/drm_gem_vram_helper.h | 18 ++ include/drm/drm_vram_mm_helper.h | 4 + 4 files changed, 198 insertions(+), 65 deletions(-) -- 2.23.0