From owner-svn-src-head@FreeBSD.ORG Tue Jul 15 15:38:05 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D17DB02; Tue, 15 Jul 2014 15:38:05 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5375F22E3; Tue, 15 Jul 2014 15:38:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8332DB97E; Tue, 15 Jul 2014 11:38:03 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: svn commit: r268624 - head/sys/dev/vt/hw/efifb Date: Tue, 15 Jul 2014 10:01:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201407141742.s6EHgMNt094168@svn.freebsd.org> <20140714175345.GK93733@kib.kiev.ua> In-Reply-To: <20140714175345.GK93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201407151001.38146.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 Jul 2014 11:38:03 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Nathan Whitehorn X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 15:38:05 -0000 On Monday, July 14, 2014 1:53:45 pm Konstantin Belousov wrote: > On Mon, Jul 14, 2014 at 05:42:22PM +0000, Nathan Whitehorn wrote: > > Author: nwhitehorn > > Date: Mon Jul 14 17:42:22 2014 > > New Revision: 268624 > > URL: http://svnweb.freebsd.org/changeset/base/268624 > > > > Log: > > On my Lenovo laptop, the firmware maps the EFI framebuffer with MTRRs set > > to uncacheable. This leads to execrable console performance. Once PMAP is > > up, remap the framebuffer as write-combining. This reduces boot time on my > > laptop by 60% when booting with EFI. > > > > MFC after: 2 weeks > > > > Modified: > > head/sys/dev/vt/hw/efifb/efifb.c > > > > Modified: head/sys/dev/vt/hw/efifb/efifb.c > > ============================================================================== > > --- head/sys/dev/vt/hw/efifb/efifb.c Mon Jul 14 17:16:09 2014 (r268623) > > +++ head/sys/dev/vt/hw/efifb/efifb.c Mon Jul 14 17:42:22 2014 (r268624) > > @@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$"); > > > > static vd_init_t vt_efifb_init; > > static vd_probe_t vt_efifb_probe; > > +static void vt_efifb_remap(void *efifb_data); > > > > static struct vt_driver vt_efifb_driver = { > > .vd_name = "efifb", > > @@ -68,6 +69,8 @@ static struct vt_driver vt_efifb_driver > > static struct fb_info local_info; > > VT_DRIVER_DECLARE(vt_efifb, vt_efifb_driver); > > > > +SYSINIT(efifb_remap, SI_SUB_KMEM, SI_ORDER_ANY, vt_efifb_remap, &local_info); > > + > > static int > > vt_efifb_probe(struct vt_device *vd) > > { > > @@ -133,9 +136,9 @@ vt_efifb_init(struct vt_device *vd) > > info->fb_size = info->fb_height * info->fb_stride; > > info->fb_pbase = efifb->fb_addr; > > /* > > - * We could use pmap_mapdev here except that the kernel pmap > > - * hasn't been created yet and hence any attempt to lock it will > > - * fail. > > + * Use the direct map as a crutch until pmap is available. Once pmap > > + * is online, the framebuffer will be remapped by vt_efifb_remap() > > + * using pmap_mapdev_attr(). > > */ > > info->fb_vbase = PHYS_TO_DMAP(efifb->fb_addr); > > > > @@ -163,3 +166,22 @@ vt_efifb_init(struct vt_device *vd) > > > > return (CN_INTERNAL); > > } > > + > > +static void > > +vt_efifb_remap(void *xinfo) > > +{ > > + struct fb_info *info = xinfo; > > + > > + if (info->fb_pbase == 0) > > + return; > > + > > + /* > > + * Remap as write-combining. This massively improves performance and > > + * happens very early in kernel initialization, when everything is > > + * still single-threaded and interrupts are off, so replacing the > > + * mapping address is safe. > > + */ > > + info->fb_vbase = (intptr_t)pmap_mapdev_attr(info->fb_pbase, > > + info->fb_size, VM_MEMATTR_WRITE_COMBINING); > > +} > > + > Could you use pmap_change_attr() ? This would save some KVA. I think that is a no-op in this case. pmap_mapdev_attr() on amd64 is already going to re-use the existing DMAP mapping after doing pmap_change_attr() on it. -- John Baldwin