Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756758AbbBEJBu (ORCPT ); Thu, 5 Feb 2015 04:01:50 -0500 Received: from mail-ob0-f169.google.com ([209.85.214.169]:33756 "EHLO mail-ob0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754783AbbBEJBs (ORCPT ); Thu, 5 Feb 2015 04:01:48 -0500 MIME-Version: 1.0 In-Reply-To: <20150203155402.4c31c36b@lxorguk.ukuu.org.uk> References: <1422504685-7864-1-git-send-email-airlied@redhat.com> <20150203155402.4c31c36b@lxorguk.ukuu.org.uk> Date: Thu, 5 Feb 2015 10:01:47 +0100 X-Google-Sender-Auth: X0q96hLZjZK3-ZcEuvCIm9vHCi8 Message-ID: Subject: Re: [PATCH] vt_buffer: drop console buffer copying optimisations From: Geert Uytterhoeven To: One Thousand Gnomes Cc: Linus Torvalds , Dave Airlie , Linux Kernel Mailing List , dri-devel@lists.sf.net, Greg Kroah-Hartman , Tomi Valkeinen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2679 Lines: 67 On Tue, Feb 3, 2015 at 4:54 PM, One Thousand Gnomes wrote: > On Thu, 29 Jan 2015 15:40:33 -0800 > Linus Torvalds wrote: > >> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/