From owner-svn-src-head@FreeBSD.ORG Tue Jul 15 15:44:14 2014 Return-Path: Delivered-To: svn-src-head@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 40996760; Tue, 15 Jul 2014 15:44:14 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (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 0501F23EA; Tue, 15 Jul 2014 15:44:13 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s6FFgu0d013809; Tue, 15 Jul 2014 10:44:01 -0500 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp2.rice.edu with ESMTP id 1n55hfr2ep-1; Tue, 15 Jul 2014 10:44:01 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id 1901B401A4; Tue, 15 Jul 2014 10:43:56 -0500 (CDT) Message-ID: <53C54C34.4090408@rice.edu> Date: Tue, 15 Jul 2014 10:43:48 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: 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> In-Reply-To: <201407151001.38146.jhb@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407150165 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:44:14 -0000 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);