grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Luna Jernberg
Subject: Re: Slow(er) loading of Grub starting after commit 887f98f0d
Date: Thu, 1 Sep 2022 20:09:03 +0200

Have this problem too

On 9/1/22, Marcel Langner via Grub-devel <grub-devel@gnu.org> wrote:
> 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
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]