memory allocator enhancements...

memory allocator enhancements...

[Vesa Jääskeläinen]

Hi All,

I have been thinking on how to improve memory allocator (thou hasn't got
too much time lately to play with it) so it could aid in following
scenarios:

1. Move VBE BIOS thunks or other code from kernel to actual driver
- specially named segment that gets allocated to lowmem in order to call
VBE BIOS extensions
- These should be located right after kernel in lowmem
- Seems to be a bit tricky to patch relocation info properly (at least
this is what I was last debugging). Ideas are welcome. Perhaps my code
was not just modified properly...

2. Allocate memory for BIOS extensions in order to support BIOS drive
mapping and El Torito or what ever someone needs.
- Probably need to make hole to memory map that is passed to OS so
allocated memory needs to be at end of lowmem so no holes within low
memory are present
- Perhaps this should be only done at last step of boot process. Eg
allocate first memory to high mem and then when boot decision has been
made, then allocate to low mem and make necessary hooks

3. Load OS image at start of highmem. I do not remember which OS needed
this thou...

4. Allocate memory for GRUB code/modules/data. This can be at end of
highmem.

Are there any other needs?

So what does people feel about these changes. I am afraid if too much
freedom is given it will make it complex...

Thanks,
Vesa Jääskeläinen

Re: memory allocator enhancements...

[phcoder]

Hello, one additional consideration is to let grub2 stay in memory even 
after OS loads. This way it would be possibly to expose any 
file/partition accessible through grub2 system as a virtual int13h disk. 
For this to be a it's very desirable to put all modules that may need to 
stay, the kernel and corresponding memory at the end of lowmem/uppermem. 
For OS loading memory at fixed address may be allocated by functions 
like grub_claimmap on ieee1275 (I have some code in this direction in my 
patch "multiboot on EFI")
Another idea is to allocate invalidatable blocks like disk cache in the 
middle of the memory. It would decrease the memory fragmentation and if 
it conflicts with any other allocation it can be easily invalidated
Vesa Jääskeläinen wrote:
> - Seems to be a bit tricky to patch relocation info properly (at least
> this is what I was last debugging). Ideas are welcome. Perhaps my code
> was not just modified properly...
In my efiemu patch I needed to do some similar things (virtual 
addressing code vs physical addressing code). You may look at my efiemu 
patch
> 
> 2. Allocate memory for BIOS extensions in order to support BIOS drive
> mapping and El Torito or what ever someone needs.
> - Probably need to make hole to memory map that is passed to OS so
> allocated memory needs to be at end of lowmem so no holes within low
> memory are present
I propose to integrate this with grub_machine_mmap_iterate. It would be like
grub_mmap_iterate - similar to grub_machine_mmap_iterate but with holes 
created by grub itself
grub_mmap_register (start,length, type) - create a memory block of type 
TYPE. This way all loaders will pass "perforated" map to their kernels.
As for kernels using BIOS I would code int15 handler.
> - Perhaps this should be only done at last step of boot process. Eg
> allocate first memory to high mem and then when boot decision has been
> made, then allocate to low mem and make necessary hooks
> 
The patch to do this "preboot hooks" is pending since september
> Are there any other needs?
For xnu resume to work fine I need to allocate a huge chunk of memory 
for hibernate image (whole memory minus few MB). It can be anywhere but 
must be contiguous.
> 
> So what does people feel about these changes. I am afraid if too much
> freedom is given it will make it complex...
> 
> Thanks,
> Vesa Jääskeläinen
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: memory allocator enhancements...

[phcoder]

phcoder wrote:
> Hello, one additional consideration is to let grub2 stay in memory even 
> after OS loads. This way it would be possibly to expose any 
> file/partition accessible through grub2 system as a virtual int13h disk. 
> For this to be a it's very desirable to put all modules that may need to 
> stay, the kernel and corresponding memory at the end of lowmem/uppermem. 
> For OS loading memory at fixed address may be allocated by functions 
> like grub_claimmap on ieee1275 (I have some code in this direction in my 
> patch "multiboot on EFI")

IMO this code needs to integrate with normal mm. Also mm can have a 
machine-dependent backend to allocate more pages or to do claimmap on 
pages normally not supposed to be in mm

> Another idea is to allocate invalidatable blocks like disk cache in the 
> middle of the memory. It would decrease the memory fragmentation and if 
> it conflicts with any other allocation it can be easily invalidated
> Vesa Jääskeläinen wrote:
>> - Seems to be a bit tricky to patch relocation info properly (at least
>> this is what I was last debugging). Ideas are welcome. Perhaps my code
>> was not just modified properly...
> In my efiemu patch I needed to do some similar things (virtual 
> addressing code vs physical addressing code). You may look at my efiemu 
> patch
>>
>> 2. Allocate memory for BIOS extensions in order to support BIOS drive
>> mapping and El Torito or what ever someone needs.
>> - Probably need to make hole to memory map that is passed to OS so
>> allocated memory needs to be at end of lowmem so no holes within low
>> memory are present
> I propose to integrate this with grub_machine_mmap_iterate. It would be 
> like
> grub_mmap_iterate - similar to grub_machine_mmap_iterate but with holes 
> created by grub itself
> grub_mmap_register (start,length, type) - create a memory block of type 
> TYPE. This way all loaders will pass "perforated" map to their kernels.
> As for kernels using BIOS I would code int15 handler.
>> - Perhaps this should be only done at last step of boot process. Eg
>> allocate first memory to high mem and then when boot decision has been
>> made, then allocate to low mem and make necessary hooks
>>
> The patch to do this "preboot hooks" is pending since september
>> Are there any other needs?
> For xnu resume to work fine I need to allocate a huge chunk of memory 
> for hibernate image (whole memory minus few MB). It can be anywhere but 
> must be contiguous.
>>
>> So what does people feel about these changes. I am afraid if too much
>> freedom is given it will make it complex...
>>
>> Thanks,
>> Vesa Jääskeläinen
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
> 
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko