[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?

> 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