Michael Kelly, le dim. 08 nov. 2026 22:41:34 +0000, a ecrit: > On 08/11/2026 22:07, Samuel Thibault wrote: > > 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().
You mean ignoring mem_upper? What value does it have on your machine? > > > 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. Ah, ok. > 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. I don't think there would be really many many holes. > Maybe a more complex heap is required? I don't think it will be necessary. If a machine has a lot of memory, it will also have some large memory area. Samuel
