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

[Robert Millan]

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."