> =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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
