Slow(er) loading of Grub starting after commit 887f98f0d

[Marcel Langner]

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