[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.
Thanks!
-Liran
>
> cheers,
> Gerd
>
More information about the SeaBIOS
mailing list