On 08/11/2026 22:07, Samuel Thibault wrote:
Re,
Michael Kelly, le dim. 08 nov. 2026 21:56:03 +0000, a ecrit:
0x20200000-0x40000000 isn't chosen for the heap because the memory hole at
0x20000000 causes multiboot's 'mem_upper' to report the limit as 0x20000000.
From what I've read, 'mem_upper' hasn't really got any value when there is a
valid memory map available. Altering biosmem_setup_allocator() to search the
range BIOSMEM_END to VM_PAGE_DIRECTMAP_LIMIT (regardless of mem_upper)
succeeds on my machine.
I can supply a very simple patch for this if you agree.
It's hard to tell if I agree with the patch if I cannot see it :)
Got me, there ! I'll supply a patch tomorrow but it's simply a case of
hardcoding 'end = VM_PAGE_DIRECTMAP_LIMIT' in biosmem_setup_allocator().
The missing room is physical as per above. The above proposal is sufficient
for my machine but given the fragmentation of the directmap by the memory
hole, it wouldn't boot with 32G, which isn't an extraordinary memory total
these days. Also on other machines, there might be more memory holes
preventing large contiguous allocations.
The allocation here is not physically contiguous. It's the virtual
mapping which will pose problem at some point.
I didn't express my point correctly. Sorry about that. What I should
have said is that it is only the largest available region that is chosen
for the heap. Since all allocations at this stage of the boot are taken
from that region some allocations might not succeed which should. The
largest region might only be a small part of the segment if there are
many holes. Maybe a more complex heap is required?
Cheers,
Mike.
