From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LgIXB-0007aI-FU for mharc-grub-devel@gnu.org; Sun, 08 Mar 2009 08:55:13 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LgIX9-0007XN-0P for grub-devel@gnu.org; Sun, 08 Mar 2009 08:55:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LgIX4-0007Rq-GC for grub-devel@gnu.org; Sun, 08 Mar 2009 08:55:09 -0400 Received: from [199.232.76.173] (port=56034 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LgIX4-0007Ri-C9 for grub-devel@gnu.org; Sun, 08 Mar 2009 08:55:06 -0400 Received: from mail-fx0-f172.google.com ([209.85.220.172]:56090) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LgIX3-0001EF-Im for grub-devel@gnu.org; Sun, 08 Mar 2009 08:55:05 -0400 Received: by fxm20 with SMTP id 20so844173fxm.42 for ; Sun, 08 Mar 2009 05:55:03 -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 :content-type:content-transfer-encoding; bh=eeByvYW5aqag1u39nl6A8TK0Ec/R+DjZoZLeNYcBpI4=; b=SGLtib/m1T1asb1oF5B6fPZKdb5ta1Qx8vTvEtRfX7krNcWUdwZ0ZgKYpG8WOHo/dV N/r7GO3Mmq4cf4OJWw5vLR7KeV9iIPJBaNEYIyLeShEWIsinkAVeU89jf7H66xKE5TTL o4OWSk0KtmqtcXu320BQTEqzT/oFG+2vbgGM4= 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:content-type:content-transfer-encoding; b=LRyGvkbizVviDnN6gejEeHq9zihjJGQxURpx7Y2/qIJ93JH33SIPmrHQkrrXco3hJJ gfeDtWF8nyF5du2aEMi0heXzcF2CKgVpTdmI9k4Byr17KZuxKeMjv2m03FmLXCnNdcmb UiotpoxjCciKHF65k1K9W6jgNeRZwKaAOxGfQ= Received: by 10.86.31.18 with SMTP id e18mr3240461fge.72.1236516903325; Sun, 08 Mar 2009 05:55:03 -0700 (PDT) Received: from ?192.168.1.25? (232-156.62-81.cust.bluewin.ch [81.62.156.232]) by mx.google.com with ESMTPS id l19sm2183197fgb.7.2009.03.08.05.55.02 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Mar 2009 05:55:02 -0700 (PDT) Message-ID: <49B3C025.5000201@gmail.com> Date: Sun, 08 Mar 2009 13:55:01 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <49B2FB1A.9040208@gmail.com> <20090308124359.GA28707@thorin> In-Reply-To: <20090308124359.GA28707@thorin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] dynamic cache allocation 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: Sun, 08 Mar 2009 12:55:11 -0000 Robert Millan wrote: > On Sat, Mar 07, 2009 at 11:54:18PM +0100, phcoder wrote: >> + grub_disk_cache_table = (struct grub_disk_cache *) >> + grub_malloc (grub_disk_cache_num * sizeof (struct grub_disk_cache)); >> [...] >> + By default use up to one quarter of memory available for allocation */ >> +#define GRUB_DISK_CACHE_DIVIDE 16536 > > I might be missing something, but I think this implies our cache will stop > working if the memory map doesn't include a contigous block that is as big > as one quarter of total memory. > It uses the indirection. The space that is allocated by this code is only for the cache index. Every index entry is 20 bytes and describes a cache entry of 4096 bytes. So for cache to work we need just a block of size of 1/800 of free allocatable memory (not the total memory but only the memory which was announced to mm.c as free). On the BIOS system with 3GB only 1/4 of available memory is announced as free (it's probably different with Vesa's new allocator). It means that cache index will take about 1MiB (about 4MiB if Vesa's allocator uses memory better) > I think we should be more conservative and define an upper bound for how > big our cache is supposed to be in a normal use case. In most cases, we'll > have as much memory available as we need for this purpose, and it's only a > few situations (i.e. machines with very low memory) that might be a problem. > > Thoughts? > -- Regards Vladimir 'phcoder' Serbinenko