Hi,just subscribed coming from arch forum (https://bbs.archlinux.org/viewtopic.php?id=279006) to report slower loading of grub after commit 887f98f0d. The additional delay is around 20s and happens right after I get the message Slot 0 opened (as I have a luks encrypted partition) and after selecting a menu entry. From what I have figured out already a new way of allocating memory more dynamically was introduced. So I played a bit with the code and figured out, that increasing the newly introduced DEFAULT_HEAP_SIZE speeds up the boot process again, until it has reached no noticeable change from before. At 2MB it was already faster loading, at 4MB I could not see any difference from before the change anymore.
My guess is that the now additional calls to get the needed memory slows down the process. Not all users that reported in the arch forum seem to be impacted. I guess it depends on what modules they use and how much memory internally is used depending on what is individually configured and how (e.g. encryption, type of root fs...).
I understood the former logic of allocation in a way that (if needed) either a maximum 1.6GB of memory is allocated or 1/4 of the installed memory. For my system the new code now starts at 1MB (instead of over 1GB) and needs to work its way up. This new way of allocating seems to try to not simply cancel if a hard coded allocation value fails but starts at a very low minimum and tries until the available system memory is really exhausted. So basically tries to also support lower memory situations better but assuming a minimum of 1MB.
So far my understanding.Assuming my findings can be supported by you, maybe an adjusted allocation scheme where 1/4 of the available memory can be used as the default and if this is not 1MB one could still cancel and throw errors?
Marcel
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
