[Top][All Lists]

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

Re: [PATCH v2 06/15] mm: Allow dynamically requesting additional memory

From: Daniel Kiper
Subject: Re: [PATCH v2 06/15] mm: Allow dynamically requesting additional memory regions
Date: Thu, 7 Apr 2022 16:02:36 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Mon, Mar 28, 2022 at 05:22:31PM +1100, Daniel Axtens wrote:
> From: Patrick Steinhardt <>
> Currently, all platforms will set up their heap on initialization of the
> platform code. While this works mostly fine, it poses some limitations
> on memory management on us. Most notably, allocating big chunks of
> memory in the gigabyte range would require us to pre-request this many
> bytes from the firmware and add it to the heap from the beginning on
> some platforms like EFI. As this isn't needed for most configurations,
> it is inefficient and may even negatively impact some usecases when,
> e.g., chainloading. Nonetheless, allocating big chunks of memory is
> required sometimes, where one example is the upcoming support for the
> Argon2 key derival function in LUKS2.
> In order to avoid pre-allocating big chunks of memory, this commit
> implements a runtime mechanism to add more pages to the system. When a
> given allocation cannot be currently satisfied, we'll call a given
> callback set up by the platform's own memory management subsystem,
> asking it to add a memory area with at least `n` bytes. If this
> succeeds, we retry searching for a valid memory region, which should now
> succeed.
> If this fails, we try asking for `n` bytes, possibly spread across
> multiple regions, in hopes that region merging means that we end up
> with enough memory for things to work out.
> Tested-by: Stefan Berger <>
> Signed-off-by: Patrick Steinhardt <>
> [dja: add this to the documentation at the top of mm.c
>       v2: fallback to non-contiguous]
> Signed-off-by: Daniel Axtens <>

Reviewed-by: Daniel Kiper <>


reply via email to

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