From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NM5By-0003IY-PB for mharc-grub-devel@gnu.org; Sat, 19 Dec 2009 14:42:18 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NM5Bw-0003HX-Gv for grub-devel@gnu.org; Sat, 19 Dec 2009 14:42:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NM5Bs-0003Ft-3R for grub-devel@gnu.org; Sat, 19 Dec 2009 14:42:16 -0500 Received: from [199.232.76.173] (port=34977 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NM5Br-0003Fq-Tm for grub-devel@gnu.org; Sat, 19 Dec 2009 14:42:11 -0500 Received: from mail-fx0-f225.google.com ([209.85.220.225]:44782) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NM5Br-0000uz-CT for grub-devel@gnu.org; Sat, 19 Dec 2009 14:42:11 -0500 Received: by fxm25 with SMTP id 25so3207877fxm.26 for ; Sat, 19 Dec 2009 11:42:10 -0800 (PST) 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=KGsrjS+xENQ70I5E2Vw6wwAToODBxHckIgdrNrMVj/U=; b=wf8dwUUDg0xZzoFBc2ILwSCSlqxJjtd95C6nGSGN7+6bSraens3dyzo6Zv2n1Qe/GD CjodhbjZFw/+vApR4R3+0Z0Gc17eJjogCN1PJ4/NhDTnSV3F9XI2iJLncdL2MerqPdgN W1fZhYFIniAnYkgnV8WccZ1xHBtat5PI0l8Mg= 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=VhRaDpBtsPaTxQv+4v9G+FAOSngtamccyiQ6ak7daQKnkyluRjJ05zqPIrqObICAAq TSObEzUWAK/vyJbRSQWtLxM68Z11ztrf1rI2EVAAxLDUDM62eAEpAB5T5D4vbmgiAKAP Mo79XVFBrF/0K2bP1KI4lZiw7vgbCnGtvwwqQ= Received: by 10.86.249.22 with SMTP id w22mr7114433fgh.1.1261251730303; Sat, 19 Dec 2009 11:42:10 -0800 (PST) Received: from debian.bg45.phnet ([81.62.88.144]) by mx.google.com with ESMTPS id d8sm9804920fga.3.2009.12.19.11.42.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 19 Dec 2009 11:42:08 -0800 (PST) Message-ID: <4B2D2C80.8020201@gmail.com> Date: Sat, 19 Dec 2009 20:41:52 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GRUB 2 References: <20090813204844.GL22130@thorin> In-Reply-To: <20090813204844.GL22130@thorin> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig37C2D2DEE285826C4DF3F08A" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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 GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 19:42:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig37C2D2DEE285826C4DF3F08A Robert Millan wrote: > On Wed, Aug 12, 2009 at 02: 45:19PM +0200, Vladimir 'phcoder' Serbinenko= wrote: > =20 >>>>> - Low memory heap (useful to move code off kern/i386/pc/startup.S)= =2E >>>>> =20 >>>> 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, jus= t >>>> 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. >>>> =20 >>> I don't understand, what is the relation between relocator in loaders= and >>> low memory heap? >>> =20 >> 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 cur= rently. >> >> 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. >> =20 > > But available memory is several orders of magnitude bigger than the lar= gest > block a loader will need. So is this really an issue? > > =20 Resume from hibernation needs a lot of memory in a single chunk --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig37C2D2DEE285826C4DF3F08A 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 iF4EAREKAAYFAkstLI4ACgkQNak7dOguQgl7GQD+JvYwmLEsCDhmrMpOFu6dXOPO 0a63iM3FOTGAVlO9FIEA/2hg0KvpxsoPugIzqijtp/waCXs7vIpPI0tpMYu1J97w =Z9a1 -----END PGP SIGNATURE----- --------------enig37C2D2DEE285826C4DF3F08A--