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: Linus Torvalds <torvalds@linux-foundation.org>,
	Dave Airlie <airlied@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel@lists.sf.net,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>
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@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