From owner-svn-src-all@FreeBSD.ORG Mon Jul 14 18:43:13 2014 Return-Path: Delivered-To: svn-src-all@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 C91BEB80; Mon, 14 Jul 2014 18:43:13 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1430262F; Mon, 14 Jul 2014 18:43:13 +0000 (UTC) Received: from zeppelin.tachypleus.net ([128.135.100.108]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s6EIh5EA006583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Jul 2014 11:43:06 -0700 Message-ID: <53C424B7.7070403@freebsd.org> Date: Mon, 14 Jul 2014 11:43:03 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: svn commit: r268624 - head/sys/dev/vt/hw/efifb References: <201407141742.s6EHgMNt094168@svn.freebsd.org> <20140714175345.GK93733@kib.kiev.ua> In-Reply-To: <20140714175345.GK93733@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;grUmsYYL5BG93muUdPQXfw== M;KC9/sYYL5BG93muUdPQXfw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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 18:43:14 -0000 On 07/14/14 10:53, 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. Does that work with the direct map? I'm pretty hesitant to muck with the direct map region this way... -Nathan