Re, Michael Kelly, le dim. 08 nov. 2026 21:56:03 +0000, a ecrit: > On 07/11/2026 14:25, Samuel Thibault wrote: > > > 1) There is a problem with my desktop machine with allocating memory for > > > the > > > (large) vm_page array for the HIGHMEM memory. I've worked around it by > > > reducing he machine memory from 16G to 8G. The problem is that the vm_page > > > array is too large to fit into a contiguous space within the DIRECTMAP > > > memory available. > > Is it physical room that is missing, or virtual room? > > (I'm surprised that 8G memory would pose that much physical room issue, > > struct vm_page is "just" a hundred bytes, so for 8G it's just 200MB ( > > With 16G in the machine, the allocation of vm_page[] is 378624k. This > doesn't fit in the heap available as determined by biosmem.c. > > I did some deeper debugging and the reason that the heap is too small is > down to: > > 1) There is a 'reserved' region in the memory map from 0x20000000-0x20200000 > which breaks the directmap segment approximately in half: > > 0x100000-0x20000000 available (size 0x1ff00000) > 0x20000000-0x20200000 reserved > 0x20200000-0x40000000 available (size 0x1fe00000) > > The first map entry starting at 0x100000 is reduced in size due to the > reserved parts (kernel and so on). That section is nevertheless chosen as > the available heap which initially shows as 0xd15b000-0x20000000. This isn't > large enough for the ~380M. > > 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 :) > > > Could that vm_page array be allocated from HIGHMEM and > > > mapped into the kernel outside of the normal kernel VM space? > > If the missing room is virtual, the physical allocation change won't > > matter. > > > > If the missing room is physical, we could probably make > > vm_page_bootalloc take highmem pages, since pmap_steal_memory maps the > > pages anyway... > > 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. Samuel
