[SeaBIOS] [PATCH 2/2] malloc: Fallback to low-zone when alloc from high-zone fails

Liran Alon liran.alon at oracle.com
Wed Nov 14 10:52:03 CET 2018

> On 14 Nov 2018, at 8:28, Gerd Hoffmann <kraxel at redhat.com> wrote:
>  Hi,
>>> There is only a tiny amount of ram available in the permanent "low"
>>> area of ram (typically less that 64K).  If the code has exhausted the
>>> permanent "high" ram (typically 256K) then it is likely to rapidly
>>> exhaust the low ram and cause a worse failure when code that requires
>>> a tiny amount of "low" space fails.
>> I disagree with “likely”.
> So it currently fails with 16 controllers.  This patch brings it how
> far?  20 controllers?  It's not like this patch scales things up much.

That’s true.

>>> Typical work arounds are to extend the amount of high ram available
>>> (see BUILD_MAX_HIGHTABLE) or to use malloc_tmphigh() and manually
>>> reserve the space in the e820 map.
>> I think this patch is good regardless if modifying BUILD_MAX_HIGHTABLE can be served as a workaround.
>> (Also if it is a typical workaround, why isn’t it configurable as a Makefile parameter?)
> Making this configurable (via kconfig) makes sense indeed.

Ok. Will create such a patch.

>> I find it odd to allocate from malloc_tmphigh() and manually reserve
>> the space in the e820 map.  As it basically undermines the definition
>> of the Temporary High-Zone which should not be reserved from OS and
>> therefore must not be accessed after SeaBIOS initialisation phase.
> pmm (see src/pmm.c) does this for large allocations.
>> Also, it is kinda hard to put the finger on which code you would
>> change to use malloc_tmphigh() like this all the time. Will you do
>> this change for example in pvscsi.c code?
> The logic in pmm could be moved to malloc.c.  Probably needs some
> refinements then, the current code is meant to handle rare and very
> large (megabytes) allocations.  In case we run out of space on small
> allocations it probably makes sense to grab a block from the tmphigh
> zone, reserve it in the e820 map and add it to the high zone pool
> instead.  So effectively the high zone can grow dynamically.

If you agree to do the logic you suggested inside malloc_high() internally
without caller being bothered with these details, then I agree this is a solution
that scales better and I will create such a patch.


> cheers,
>  Gerd

More information about the SeaBIOS mailing list