Re: Policy-based memory allocations (was Re: RFC: 1.97 roadmap)

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

signature.asc
Description: OpenPGP digital signature