From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KLNCg-00051C-3l for mharc-grub-devel@gnu.org; Tue, 22 Jul 2008 15:07:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLNCe-000517-7J for grub-devel@gnu.org; Tue, 22 Jul 2008 15:07:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLNCb-00050u-Su for grub-devel@gnu.org; Tue, 22 Jul 2008 15:07:15 -0400 Received: from [199.232.76.173] (port=40407 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLNCb-00050r-Md for grub-devel@gnu.org; Tue, 22 Jul 2008 15:07:13 -0400 Received: from gateway06.websitewelcome.com ([67.18.103.12]:48366) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KLNCa-0004GQ-GH for grub-devel@gnu.org; Tue, 22 Jul 2008 15:07:12 -0400 Received: (qmail 6661 invoked from network); 22 Jul 2008 19:14:47 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway06.websitewelcome.com with SMTP; 22 Jul 2008 19:14:47 -0000 Received: from spk.venturedesignservices.com ([65.61.115.34]:27141 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KLNCX-0005mM-3g; Tue, 22 Jul 2008 14:07:09 -0500 Date: Tue, 22 Jul 2008 12:06:32 -0700 From: Colin D Bennett To: The development of GRUB 2 Message-ID: <20080722120632.7aa611ce@gibibit.com> In-Reply-To: <1216752511.5029.4.camel@dv> References: <20080722084347.53863920@gibibit.com> <1216752511.5029.4.camel@dv> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/5wBPyPXnaAR4oa1r4n96GfR"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Cc: proski@gnu.org Subject: Re: [PATCH] File readahead buffering X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 19:07:16 -0000 --Sig_/5wBPyPXnaAR4oa1r4n96GfR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 22 Jul 2008 14:48:31 -0400 Pavel Roskin wrote: > On Tue, 2008-07-22 at 08:43 -0700, Colin D Bennett wrote: > > This patch speeds up loading a TGA image on my test system from 29 > > seconds to approximately 1 second. > >=20 > > I noticed that on my 1 GHz test system running from an IDE > > CompactFlash drive, loading a certain TGA image in GRUB takes about > > 29 seconds. >=20 > I'm sorry for straying from your point, but maybe we should drop TGA > support. It was the first image format for GRUB to support, but now > PNG is supported, and it should be better in all aspects. I agree that TGA is not, in general, a great choice for an image format (unless it is faster to load a large background image -- a 1024x768 RGB PNG file may take more time to decompress than a TGA image would take to load -- although perhaps an uncompressed PNG file would be comparable in speed to load). However, I have not been able to load any PNG images that I have tried to use. Something about the chunk type not being supported. > > It turns out that when booting GRUB from IDE, if file buffering is > > used, GRUB hangs right after the "GRUB" message, early in the boot > > process. So I added a flag that allows grub_main() to enable > > buffering when it is safe to do so. It always worked file from an > > ISO image (generated with grub-mkrescue) in VMware and QEMU, but > > when I actually installed GRUB to my CompactFlash drive and booted > > it, it hung after "GRUB" if file buffering was enabled at the start. >=20 > I think we should be prefer simple and reliable code, rather than add > complexity and risks of failure to achieve higher speeds. If the buffering is not done in the file I/O layer, then the font loading, theme file loading, image file loading, etc. will all need to do their own buffering, which IMHO is more error prone and makes those modules use more code to handle low level I/O stuff, which detracts from their specific purpose. Also, this is no small increase in speed, but from 10x to 100x increase in performance for some cases where small sequential reads are performed. Regards, Colin --Sig_/5wBPyPXnaAR4oa1r4n96GfR Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiGL7oACgkQokx8fzcGbYeW2wCcCufVByJQSMdptG/uncgVb9q/ XIQAn1z3BubzxBq32gL4a5D7CaV3Zs8X =xfEc -----END PGP SIGNATURE----- --Sig_/5wBPyPXnaAR4oa1r4n96GfR--