From owner-svn-src-all@FreeBSD.ORG Mon Jul 14 17:53:52 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2ABF797; Mon, 14 Jul 2014 17:53:51 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 773982194; Mon, 14 Jul 2014 17:53:51 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6EHrjnB019588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jul 2014 20:53:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s6EHrjnB019588 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6EHrjpV019587; Mon, 14 Jul 2014 20:53:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 14 Jul 2014 20:53:45 +0300 From: Konstantin Belousov To: Nathan Whitehorn Subject: Re: svn commit: r268624 - head/sys/dev/vt/hw/efifb Message-ID: <20140714175345.GK93733@kib.kiev.ua> References: <201407141742.s6EHgMNt094168@svn.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UQu++aFZ1G7bq4T5" Content-Disposition: inline In-Reply-To: <201407141742.s6EHgMNt094168@svn.freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 17:53:52 -0000 --UQu++aFZ1G7bq4T5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 >=20 > Log: > On my Lenovo laptop, the firmware maps the EFI framebuffer with MTRRs s= et > 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. > =20 > MFC after: 2 weeks >=20 > Modified: > head/sys/dev/vt/hw/efifb/efifb.c >=20 > Modified: head/sys/dev/vt/hw/efifb/efifb.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- 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$"); > =20 > static vd_init_t vt_efifb_init; > static vd_probe_t vt_efifb_probe; > +static void vt_efifb_remap(void *efifb_data); > =20 > static struct vt_driver vt_efifb_driver =3D { > .vd_name =3D "efifb", > @@ -68,6 +69,8 @@ static struct vt_driver vt_efifb_driver=20 > static struct fb_info local_info; > VT_DRIVER_DECLARE(vt_efifb, vt_efifb_driver); > =20 > +SYSINIT(efifb_remap, SI_SUB_KMEM, SI_ORDER_ANY, vt_efifb_remap, &local_i= nfo); > + > static int > vt_efifb_probe(struct vt_device *vd) > { > @@ -133,9 +136,9 @@ vt_efifb_init(struct vt_device *vd) > info->fb_size =3D info->fb_height * info->fb_stride; > info->fb_pbase =3D 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 =3D PHYS_TO_DMAP(efifb->fb_addr); > =20 > @@ -163,3 +166,22 @@ vt_efifb_init(struct vt_device *vd) > =20 > return (CN_INTERNAL); > } > + > +static void > +vt_efifb_remap(void *xinfo) > +{ > + struct fb_info *info =3D xinfo; > + > + if (info->fb_pbase =3D=3D 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 =3D (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. --UQu++aFZ1G7bq4T5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTxBkpAAoJEJDCuSvBvK1BWD0QAIr3MWdSesuImzjg55kN0RFG Hc3Xwz3uHw8NS+fg1VD2ldSjxASXAWb3pBYDa/l7qQVOSHEZsurinL5QIf3G5e84 S+Uv7tTcwdRekBfxLrDNVMq6ruuqkucXvAFYlsq67CwOFq+9uUj8kRuDLYtJR71u fR9UO+6r2sqly2cuBVyauxtTQIXDIUYSQ52KRRMnAGWm+9jl8SgZef85eaNHwVJg ubeidpJ7ueV3qnFAAyMTCKq7uxnYGNWvdsHht+M6pbqWYU8/5FCazHfzHZtwyLD+ VuuXHxHAh+khaCjVCbf/L4CotTDN2dUgwxH4UZ6NrwQKfel9x/UOuMu5/p0J5OO8 7ErN7rlIL4+/SMct3nWsHdWoIfi2qlEbtQAPA6zI2KxtRpW3rB6T54vgoI2SQcsW T7jglooJ/2B0jd0PDWptYq0AUTcXGIPMcIJWa4pghFByOAG4Wdi1HF/1BoOL7FzO ZU8G6gH/kEppzPk5rTdPTpCQ1ildp3yP8WhngFhR1zReelzIQxHqiSFg0zF1P4li yM9ZU13Pn/T1rthCYVi11K0nKFlbAC8NNpbTjJ8hStWQAK8FjJCEaRMQP2agT9va uvly6wApmEm90WAwU7lyfxWB2E7Gie4g9SsgKw9OiqKNyFMAHSwnzd9ql0PX7YKQ UvwsrtDrnk3omMW298P8 =z9Nu -----END PGP SIGNATURE----- --UQu++aFZ1G7bq4T5--