lkml.org 
[lkml]   [2015]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] vt_buffer: drop console buffer copying optimisations
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.

Is it reads or writes that kill the card ?

Also note that switching to lots of small writes may break the 3Dfx
driver for the early 3Dfx PCI cards - they are really quite touchy about
how they are fed.

Unfortunately fbcon still matters for dumb EFI framebuffer fallbacks.

vgacon it doesn't matter (if it was too slow you could make vgacon as
fast as you want by only updating the off screen characters once per
vertical blank). fbcon that is a bit harder as you are allowed to
scribble on the display as well. You can't even check open/mmapped as you
can open, scribble and close.

Alan


\
 
 \ /
  Last update: 2015-02-03 17:01    [W:0.216 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site