All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Policy-based memory allocations (was Re: RFC: 1.97 roadmap)
Date: Sat, 19 Dec 2009 20:41:52 +0100	[thread overview]
Message-ID: <4B2D2C80.8020201@gmail.com> (raw)
In-Reply-To: <20090813204844.GL22130@thorin>

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

>  =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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

      parent reply	other threads:[~2009-12-19 19:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-12 12:45 Policy-based memory allocations (was Re: RFC: 1.97 roadmap) Vladimir 'phcoder' Serbinenko
2009-08-13 20:48 ` Robert Millan
2009-08-13 21:01   ` Vladimir 'phcoder' Serbinenko
2009-08-16 19:35     ` [RFT] " Vladimir 'phcoder' Serbinenko
2009-08-17 13:04       ` Robert Millan
2009-12-19 19:41   ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B2D2C80.8020201@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.