From owner-svn-src-all@FreeBSD.ORG Wed Jul 16 02:37:12 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 0E225C2B; Wed, 16 Jul 2014 02:37:12 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 E7B30206A; Wed, 16 Jul 2014 02:37:11 +0000 (UTC) Received: from zeppelin.tachypleus.net (173-161-16-229-Illinois.hfc.comcastbusiness.net [173.161.16.229]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s6G2b6GW025615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 19:37:07 -0700 Message-ID: <53C5E552.3040307@freebsd.org> Date: Tue, 15 Jul 2014 19:37:06 -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: Alan Cox , John Baldwin , Konstantin Belousov Subject: Re: svn commit: r268624 - head/sys/dev/vt/hw/efifb References: <201407141742.s6EHgMNt094168@svn.freebsd.org> <20140714175345.GK93733@kib.kiev.ua> <201407151001.38146.jhb@freebsd.org> <53C54C34.4090408@rice.edu> In-Reply-To: <53C54C34.4090408@rice.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;GG/CE5IM5BGBYk2zUc16mQ== M;qlcuFJIM5BGBYk2zUc16mQ== 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: Wed, 16 Jul 2014 02:37:12 -0000 On 07/15/14 08:43, Alan Cox wrote: > On 07/15/2014 09:01, John Baldwin wrote: >> 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. >> > Yes, it automatically uses the direct map: > > void * > pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode) > { > vm_offset_t va, offset; > vm_size_t tmpsize; > > /* > * If the specified range of physical addresses fits within the > direct > * map window, use the direct map. > */ > if (pa < dmaplimit && pa + size < dmaplimit) { > va = PHYS_TO_DMAP(pa); > if (!pmap_change_attr(va, size, mode)) > return ((void *)va); > > Well, I'm glad I didn't fix it earlier :) -Nathan