[PATCH] vt_buffer: drop console buffer copying optimisations
Greg Kroah-Hartman
gregkh at linuxfoundation.org
Thu Jan 29 15:57:42 PST 2015
On Thu, Jan 29, 2015 at 03:40:33PM -0800, Linus Torvalds wrote:
> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie <airlied at 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?
I can take this through the tty tree, but can I put it in linux-next and
wait for the 3.20 merge window to give people who might notice a
slow-down a chance to object?
thanks,
greg k-h
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
--
_______________________________________________
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
More information about the dri-devel
mailing list