[PATCH v2 0/3] ast, mgag200: Map console BO while it's being displayed
Daniel Vetter
daniel at ffwll.ch
Wed Sep 4 12:13:13 UTC 2019
On Wed, Sep 4, 2019 at 1:56 PM Thomas Zimmermann <tzimmermann at suse.de> wrote:
>
> (was: drm/vram-helper: Fix performance regression in fbdev)
>
> 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.
>
> This patch set fixes the problem by adding a ref counter to the GEM
> VRAM buffers' kmap operation, and keeping the fbdev's console buffer
> mapped while the console is being displayed. These changes avoid the
> frequent mappings in the fbdev code. The drivers, ast and mgag200,
> map the console's buffer when it becomes visible and the fbdev code
> reuses this mapping. The original fbdev code in ast and mgag200 used
> the same strategy.
>
> [1] https://lists.freedesktop.org/archives/dri-devel/2019-September/234308.html
As discussed on irc a bit, here's my thoughts:
- imo we should fix this by using the io_mapping stuff, that avoids
the overhead of repeated pat checks for map/unmap. It should also cut
down on remapping costs a lot in general (at least on 64bit kernels,
which is like everything nowadays). But it's a lot more work to roll
out I guess. I think this would be the much better longterm fix.
- this here only works when fbcon is active, the noise will come back
when you start X or wayland. We should probably check whether the
display is active with drm_master_internal_acquire (and reupload when
we restore the entire console in the restore function - could just
launch the worker for that).
I'm also not sure whether we have a real problem here, it's just debug
noise that we're fighting here?
-Daniel
>
> v2:
> * fixed comment typos
>
> Thomas Zimmermann (3):
> drm/vram: Add kmap ref-counting to GEM VRAM objects
> drm/ast: Map fbdev framebuffer while it's being displayed
> drm/mgag200: Map fbdev framebuffer while it's being displayed
>
> drivers/gpu/drm/ast/ast_mode.c | 19 +++++++
> drivers/gpu/drm/drm_gem_vram_helper.c | 74 +++++++++++++++++++-------
> drivers/gpu/drm/mgag200/mgag200_mode.c | 20 +++++++
> include/drm/drm_gem_vram_helper.h | 19 +++++++
> 4 files changed, 114 insertions(+), 18 deletions(-)
>
> --
> 2.23.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel
mailing list