From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OTARb-0003Zl-ER for mharc-grub-devel@gnu.org; Mon, 28 Jun 2010 05:15:59 -0400 Received: from [140.186.70.92] (port=52562 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OTAQq-00038C-7c for grub-devel@gnu.org; Mon, 28 Jun 2010 05:15:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OTAQG-0005nl-1C for grub-devel@gnu.org; Mon, 28 Jun 2010 05:15:12 -0400 Received: from mail-bw0-f41.google.com ([209.85.214.41]:54182) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OTAQF-0005na-Oa for grub-devel@gnu.org; Mon, 28 Jun 2010 05:14:36 -0400 Received: by bwz9 with SMTP id 9so663321bwz.0 for ; Mon, 28 Jun 2010 02:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=cIvw36iUv60b0kU6VDMFraWHrDOKaGZGXW2e8BJSTcQ=; b=oTnZCtivXKz90Be741mAbgDxKVYqfDyKxcZgJyakZdl9AYyJF5Z3OyWMOX+EegNnig AR0qwlKzqpEhWjXTMczkqQ0xuXKilz3KKQHQ2Otz9Qxw6e+oDJLAGh1RYDG9VaLxj98N ZpRRyCHlvk1Bb8xvzYuuTnBq/ugh5GdGHWTOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=S7OAzDLPYklgq/CgovXj5LM0V+ysztm0E8yl/7jxxmjgtzBzAsuOV0xJHC8i+YZ2Ij ERIJjkSAq366WUG9OAEcBdy2rZd03BlTjE7FA6Brm7Cp7kPLAuwsYF4htCnUWFi9b7ss lGe7bkvJ/rq+D1fnjn86eDgRIbx97/wDqDZ5k= Received: by 10.204.6.10 with SMTP id 10mr3312739bkx.191.1277716474531; Mon, 28 Jun 2010 02:14:34 -0700 (PDT) Received: from debian.bg45.phnet ([81.62.191.77]) by mx.google.com with ESMTPS id u3sm17712439bkz.12.2010.06.28.02.14.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 02:14:33 -0700 (PDT) Message-ID: <4C2867F1.9040805@gmail.com> Date: Mon, 28 Jun 2010 11:14:25 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: grub-devel@gnu.org References: <20100625085834.GM21862@riva.ucam.org> In-Reply-To: <20100625085834.GM21862@riva.ucam.org> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0A3B7345656FFDA87196A893" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [RFC] Hacky MTRR support X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 09:15:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A3B7345656FFDA87196A893 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/25/2010 10:58 AM, Colin Watson wrote: > I recently posted ("Subject: [PATCH] Optimise memset on i386" - sorry, = I > don't seem to have a route to lists.gnu.org at the moment so I can't > post an archive link) about optimising GRUB's video initialisation, and= > hinted that it might be possible to do better by implementing MTRRs as > well in order to allow the system to combine writes to video memory > rather than taking a cache stall for every single write. I can report > that, at least on the hardware I was using, it does make a significant > difference: filling the screen with solid colour now takes 10 > milliseconds rather than 160! This ended up shaving about a second off= > the boot time of the project I'm working on. > > On Linux, you can tell whether this is likely to be the case by > comparing the kernel log from startup with /proc/mtrr. For example, on= > my Dell Latitude D830 with BIOS version A02, the kernel log says: > > MTRR variable ranges enabled: > 0 base 000000000 mask F80000000 write-back > 1 base 080000000 mask FC0000000 write-back > 2 base 0BF800000 mask FFF800000 uncachable > 3 base 0BF700000 mask FFFF00000 uncachable > 4 disabled > 5 disabled > 6 disabled > 7 disabled > > ... while /proc/mtrr says: > > reg00: base=3D0x000000000 ( 0MB), size=3D 2048MB, count=3D1: write= -back > reg01: base=3D0x080000000 ( 2048MB), size=3D 1024MB, count=3D1: write= -back > reg02: base=3D0x0bf800000 ( 3064MB), size=3D 8MB, count=3D1: uncac= hable > reg03: base=3D0x0bf700000 ( 3063MB), size=3D 1MB, count=3D1: uncac= hable > reg04: base=3D0x0e0000000 ( 3584MB), size=3D 256MB, count=3D1: write= -combining > > The extra write-combining entry there matches the video memory aperture= > (you can check this by comparing with /proc/iomem and 'lspci -vvnn'), > and I think it's set up by the X driver. > > The following patch is against 1.98, since that's what I was developing= > on. I'm not posting this as a serious merge proposal right now so I > haven't included a ChangeLog or anything; this is just an RFC, and migh= t > be useful for others interested in this kind of thing (Seth Goldberg > commented on IRC that he had been looking into something similar). > > Flaws in this approach include: > > * Doesn't work with anything other than the generic Intel MTRR system= > (although modern AMD chips have this too) > > * Very simplistic MTRR handling: anything other than a card with a > power-of-two memory region aligned on a same-power-of-two boundary > will degrade to previous behaviour > > * Might break older cards where write-combining isn't permitted (I > found an Intel paper saying such cards existed); in particular it's= > possible that some cards might put registers in that region > > * Entirely unconfigurable > > It's also probably in the wrong place in the tree; I imagine EFI driver= s > would want to do much the same thing, for example - and my patch has fa= r > too many magic constants. I did at least take care to disable any MTRR= > added by GRUB before starting the target kernel; who knows what effects= > that might have, especially on multiprocessor systems (although Linux > does work around out-of-sync MTRRs across CPUs). > > Still, I'd like to know whether this is of general enough interest to > merit polishing it up and maybe offering it as some kind of configurabl= e > option. I do think that this is a BIOS bug, but it seems to be a not > uncommon one and it does have a pretty noticeable effect on GRUB's vide= o > performance. > > =20 In GRUB the stability is more important than speed. So blindly enabling this on all cards would be bad. Perhaps it's better to enable MTRR only with native drivers or at least have PCIID whitelist. It's worth doing but we have to be cautious about it x86 is particular in that uncached and buffered addresses are the same. On MIPS it's not the case. I think it's better to add an argument to grub_pci_device_map_range/grub_pci_device_unmap_range. > +#define cpuid(num,a,b,c,d) \ > + asm volatile ("xchgl %%ebx, %1; cpuid; xchgl %%ebx, %1" \ > + : "=3Da" (a), "=3Dr" (b), "=3Dc" (c), "=3Dd" (d) \ > + : "0" (num)) > + > =20 We already have cpuid functions in tsc.h. I've seen other uncleannesses but as you said it's meant only as a demo --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig0A3B7345656FFDA87196A893 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAkwoZ/EACgkQNak7dOguQgnZ4QD/ZLuLy2sKRLiLVEce5lsUloOV b7J+GRvgXgrsr+4KGNMA/18CkYG6iKnD+EL3BEkoXhy0jfOw7vTS6DXosafhiIOi =lewI -----END PGP SIGNATURE----- --------------enig0A3B7345656FFDA87196A893--