From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MbhEI-00018p-E2 for mharc-grub-devel@gnu.org; Thu, 13 Aug 2009 16:48:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbhEG-00015j-M6 for grub-devel@gnu.org; Thu, 13 Aug 2009 16:48:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbhEC-0000yg-QW for grub-devel@gnu.org; Thu, 13 Aug 2009 16:48:56 -0400 Received: from [199.232.76.173] (port=38462 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbhEC-0000yC-GR for grub-devel@gnu.org; Thu, 13 Aug 2009 16:48:52 -0400 Received: from xvm-190-8.ghst.net ([217.70.190.8]:35870 helo=aybabtu.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MbhEB-0000Dm-W6 for grub-devel@gnu.org; Thu, 13 Aug 2009 16:48:52 -0400 Received: from [192.168.10.10] (helo=thorin) by aybabtu.com with esmtp (Exim 4.69) (envelope-from ) id 1MbhE9-0000WS-M8 for grub-devel@gnu.org; Thu, 13 Aug 2009 22:48:50 +0200 Received: from rmh by thorin with local (Exim 4.69) (envelope-from ) id 1MbhE4-0005zf-Ln for grub-devel@gnu.org; Thu, 13 Aug 2009 22:48:44 +0200 Date: Thu, 13 Aug 2009 22:48:44 +0200 From: Robert Millan To: The development of GRUB 2 Message-ID: <20090813204844.GL22130@thorin> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: Policy-based memory allocations (was Re: RFC: 1.97 roadmap) 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: Thu, 13 Aug 2009 20:48:57 -0000 On Wed, Aug 12, 2009 at 02:45:19PM +0200, Vladimir 'phcoder' Serbinenko wrote: > >> >  - Low memory heap (useful to move code off kern/i386/pc/startup.S). > >> Originally I thought of a path relocator32->relocator users->mm > >> relocator32 is ready for next round of review but is untested. Now I > >> think about it mm patch isn't actually dependent on relocator32, just > >> you won't get some features (as loading big initrds and removal of > >> os_area_size/os_area_addr fields) before relocator32 is used by all > >> loaders. I will adjust mm patch to this and add > >> .(text|data|bss)-lowmem section support. > > > > I don't understand, what is the relation between relocator in loaders and > > low memory heap? > Actually low memory heap is a special case of policy based allocation. > My design is: > I have up to 4 different policies (can be more by modifying defines > but has to be hardcoded for performance reasons and multiple of 4 for > alignment reasons) > Every region knows which allocator it has to use together with which > policy. Current allocators: > -Skip. Don't use this region with given policy > -First. Try to allocate as low as possible > -Last. Try to allocate as high as possible > -Second. Allocate second free chunk from region. It's what is used currently. > > The idea behind that design is that often loaders need a big > continuous chunk of memory so if loaders get memory from bottom and > the rest takes memory from top we're likely to have a chunk of > necessary size available. But available memory is several orders of magnitude bigger than the largest block a loader will need. So is this really an issue? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."