[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vladimir 'phcoder' Serbinenko
Subject: Policy-based memory allocations (was Re: RFC: 1.97 roadmap)
Date: Wed, 12 Aug 2009 14:45:19 +0200

>> >  - 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.
To take advantage of this design kernel area (first 3/4 of memory
which aren't added to heap) has to be eliminated. For this to happen
all loaders have to use relocator.

However I can make patches without need of relocator (w/o eliminating
kernel area). Just you won't get all the advantages of policy-based
> I'll need to catch up with the lowmem heap discussion.  What's the approach?
>> What about savedefault? Which savedefault way you prefer?
> I think it would be good to have.  But I haven't followed on the savedefault
> discussion, I just know it would build upon the existing envfile support.
>> > Bigger overhauls like the fancy menu
>> I started splitting Collin's patches and actually only quite few need
>> to go to the parts already present in grub2. Perhaps 1.97 can be
>> brought to a state when gfxmenu can be compiled externally?
> Depends on how intrusive are those changes :-)
I'll present them and I'm ok if they are postponed.
> --
> 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."
> _______________________________________________
> Grub-devel mailing list
> address@hidden

Vladimir 'phcoder' Serbinenko

Personal git repository:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]