Michael Kelly, le jeu. 19 févr. 2026 07:52:41 +0000, a ecrit: > On 19/02/2026 07:02, Samuel Thibault wrote: > > Hello, > > > > Michael Kelly, le jeu. 19 févr. 2026 06:02:36 +0000, a ecrit: > > > I ran that sequence for around 30 > > > successful builds until my virtual machine locked up with a panic: > > > > > > panic ../vm/vm_page.c:1618: vm_page_alloc_pa: vm_page: privileged thread > > > unable to allocate page > > Which is essentially an out of memory situation. In principle the > > swapping code tries to keep on the safe side to make sure privileged > > threads can allocate, but "privileged threads" is probably too > > inclusive. AFAIK only the default pager and rumpdisk get privileged. > > There is also notably vm_map_lock() that gets privileged. Is the > > backtrace of this panic after a vm_map_lock()? > > On a 2GB i386 virtual machine there should be around 100M remaining when > normal allocation is paused. That is a lot of memory being used by > privileged threads thereafter to satisfy the pageout.
Yes, but note that other non-pageout-related privileged threads can allocate memory while paging out. That's still quite a lot indeed. > I think that something > is going wrong and I'll be looking into it over the days ahead. > > One instance that occurred whilst building haskell-hedgehog: > > login: panic ../vm/vm_page.c:1618: vm_page_alloc_pa: vm_page: privileged > thread unable to allocate page > Debugger invoked: panic > Kernel Breakpoint trap, eip 0xffffffff8100c956, code 0, cr2 ffffffffb2e19b00 > Stopped at Debugger+0x15: TODO > Debugger(...)+0x15 > Panic(...)+0xb8 > vm_page_alloc_pa(...)+0x2da > vm_page_convert(...)+0x57 > vm_fault_page(...)+0x832 > vm_fault(...)+0x5d0 > vm_fault_wire(...)+0x75 > vm_map_pageable_scan(...)+0x154 > vm_map_protect(...)+0x1c5 So it's inside a vm_map_lock() indeed. I'm thinking that on non-vm_privileged threads, we could perhaps make vm_map_lock() block as long as memory is low. The vm_privilege escalation there is meant to make sure the section progresses in case we got memory low in between, but if memory is already low on entry, we can just make the caller block. Samuel > vm_protect(...)+0x62 > _Xvm_protect(...)+0x7e > ipc_kobject_server(...)+0xac > mach_msg_trap(...)+0x8a0 > syscall64(...)+0xe3 > > And another whilst running stress-ng. This thread is rumpdisk.server: > > db> trace /tu $task3.22 > Debugger(c10f69a0,f6a20c38,1,c10009bf,3c7)+0x13 > Panic(c10ee02a,652,c10d649c,c10dd9e4,f6a20ce8)+0x7a > vm_page_alloc_pa(0,3,3,c1010d08)+0x23f > vm_page_convert(f672fd60,d79240b0,0,c10421d5,0)+0x48 > vm_fault_page(d79240b0,0,3,0,0,f672fddc,f672fde0,f672fde4,0,0,f672fddc,c1010cc0) > +0xd29 > vm_fault(f59ecec8,72f9000,3,1,0,0,f04cda58,0)+0x52a > vm_fault_wire(f59ecec8,f04cda58,80001513,f672fee0,f59ecec8)+0x66 > vm_map_pageable_scan(c1047c8c,f59ecec8,f59eced0,f04cda58,f59ecec8)+0x107 > vm_map_pageable(f59ecec8,72f9000,72fa000,3,0,0,1,f04cda68)+0x106 > vm_map_enter(f59ecec8,f672ffb0,1000,0,1,0,0,0,3,7,1,30)+0x3dd > vm_allocate(f59ecec8,f672ffb0,1000,1,cbaace8,f672ffb0,4,c1032e41)+0x4b > syscall_vm_allocate(2,cbaace8,1000,1,f612d440)+0x35 > >>>>> user space <<<<< > syscall_vm_allocate(0x82401bc)(0x81b01f3(2,cbaace8,1000,1,1000) > rumpdisk_device_read(0x8049f5c)(20069e50,7e,12,0,135b08) > _Xdevice_read(0x804cd6e)(cbaae30,cbace40,cbaad98,cbaef3c,cbace40) > machdev_demuxer(0x804a93b)(cbaae30,cbace40,cbaaddc,0,cbace40) > synchronized_demuxer(0x804dfbb)(cbaae30,cbace40,0,0,1712) > mach_msg_server_timeout(0x81b0818)(cbaeee8,2000,10,900,2710) > thread_function(0x804e0eb)(1,10000,0,0,0) > ports_manage_port_operations_multithread(0x804e329)(20002d90,8049c70,1d4c0,927c0,0) > rumpdisk_multithread_server(0x8049c5f)(0,837bd74,cbaefe8,819df45,0)
