You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, GRUB tends to place the boot component into physical memory significantly offset from the end of the kernel. There is, as far as I can see, very little reason for this offset.
This proposal is to mem_move (note we can't memcpy) the booter to be physically contiguous with the kernel memory during the early boot process (i.e. modifications in kernel.c) while updating where the boot-time dynamic allocations, and untyped memory are located. These will overlap with the current boot component memory, so it will likely need to be zero-ed out. This will reclaim around 10MB-50MB of memory which is lost for no real reason.
The text was updated successfully, but these errors were encountered:
Not really. It is a straightforward change as far as I can tell, but one that is lower priority at this point than other things (tcaps, embedded VM, cbufs on Speck, etc...).
BTW, in the above, I certainly meant memmove. My mistake.
Currently, GRUB tends to place the boot component into physical memory significantly offset from the end of the kernel. There is, as far as I can see, very little reason for this offset.
This proposal is to
mem_move
(note we can'tmemcpy
) the booter to be physically contiguous with the kernel memory during the early boot process (i.e. modifications inkernel.c
) while updating where the boot-time dynamic allocations, and untyped memory are located. These will overlap with the current boot component memory, so it will likely need to be zero-ed out. This will reclaim around 10MB-50MB of memory which is lost for no real reason.The text was updated successfully, but these errors were encountered: