> On 14 Nov 2018, at 8:28, Gerd Hoffmann <kra...@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 > _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
