Messages in this thread | | | Date | Thu, 29 Jan 2015 15:40:33 -0800 | Subject | Re: [PATCH] vt_buffer: drop console buffer copying optimisations | From | Linus Torvalds <> |
| |
On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie <airlied@redhat.com> wrote: > > Linus, this came up a while back I finally got some confirmation > that it fixes those servers.
I'm certainly ok with this. which way should it go in? The users are:
- drivers/tty/vt/vt.c (Greg KH, "tty layer")
- drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)
and it might make sense to have *some* indication of how much worse this makes fbcon performance in particular..
Greg/Tomi - the patch is removing this:
#define scr_memcpyw(d, s, c) memcpy(d, s, c) #define scr_memmovew(d, s, c) memmove(d, s, c) #define VT_BUF_HAVE_MEMCPYW #define VT_BUF_HAVE_MEMMOVEW
from <linux/vt_buffer.h>, because some stupid graphics cards apparently cannot handle 64-bit accesses of regular memcpy/memmove.
And on other setups, this will be the reverse: 8-bit accesses due to using "rep movsb", which is the fast way to move/clear memory on modern Intel CPU's, but is really wrong for MMIO where it will be slow as hell.
So just getting rid of the memcpy/memmove is likely the right thing in general, since the fallbacks go this the traditional 16-bit-at-a-time way. And getting rid of the memcpy _may_ speed things up.
But if it slows things down, we might have to try something else. Like saying "all cards we've ever seen have been ok with aligned 32-bit accesses", and extend the open-coded scr_memcpy/memmove functions to do that.
Hmm?
Linus
| |