Re: [PATCH] vt_buffer: drop console buffer copying optimisations

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	dri-devel@lists.sf.net, Dave Airlie <airlied@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] vt_buffer: drop console buffer copying optimisations
Date: Thu, 5 Feb 2015 10:01:47 +0100	[thread overview]
Message-ID: <CAMuHMdUOrd3vsOWPDDWGpkrdCo+SoHWv+SXuEXWxuGnL1FQRsQ__37601.2074914344$1423189039$gmane$org@mail.gmail.com> (raw)
In-Reply-To: <20150203155402.4c31c36b@lxorguk.ukuu.org.uk>

On Tue, Feb 3, 2015 at 4:54 PM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
> On Thu, 29 Jan 2015 15:40:33 -0800
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> 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..
>
> For devices that have no hardware scrolling it used to be double digit
> percentages difference between 32 and 64bit when reading from the fb
> because the reads are not posted and the latency killed you. Writes - not
> so big a deal - but the bridge should combine them anyway. I imagine
> 16bit read would be unprintably bad.

Fbcon uses scr_mem{cpy,move}w() for the VT buffer (characters + attributes)
only, not for the frame buffer data.
So the performance degradation should be minimal.

However, as this affects real VGA on x86 only, perhaps it can be fixed
in arch/x86/include/asm/vga.h instead of include/linux/vt_buffer.h, so
platforms not having VGA are not affected? We have these VT_BUF_*
and scr_*() abstractions for a reason...

If I'm not mistaken, that would be as simple as adding

    #define VT_BUF_HAVE_RW.
    #define scr_writew(val, addr) (*(addr) = (val))
    #define scr_readw(addr) (*(addr))

to arch/x86/include/asm/vga.h.

If someone wants to put one of the "bad" VGA cards in a non-x86 PCI slot,
perhaps a few more architecture-specific asm/vga.h have to be updated:

$ git grep -w VT_BUF_HAVE_RW -- arch
arch/alpha/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/mips/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/powerpc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/sparc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/tile/include/asm/vga.h:#define VT_BUF_HAVE_RW

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel