On Wed, Jul 24, 2019 at 03:22:31PM -0700, Mike Larkin wrote:
> If this happens again, it might be interesting to see what pages around
> that are mapped.
They are not mapped.
uvm_fault(0xffffffff81da8270, 0x7f826ae62830, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at pmap_page_remove+0x210: xchgq %rax,0(%rcx,%rdx,1)
ddb{0}> trace
pmap_page_remove(fffffd810b60de00) at pmap_page_remove+0x210
uvm_anfree(fffffd816a8396d0) at uvm_anfree+0x36
amap_wipeout(fffffd827f101138) at amap_wipeout+0xe5
uvm_unmap_detach(ffff800021eba398,1) at uvm_unmap_detach+0xef
uvm_map_teardown(fffffd823df509a0) at uvm_map_teardown+0x1c1
uvmspace_free(fffffd823df509a0) at uvmspace_free+0x57
uvm_exit(ffff800021eee038) at uvm_exit+0x24
reaper(ffff8000ffff89e8) at reaper+0x13b
end trace frame: 0x0, count: -8
ddb{0}> x/x 0x7f826ae62000
0x7f826ae62000:uvm_fault(0xffffffff81da8270, 0x7f826ae62000, 0, 1) -> e
kernel: page fault trap, code=0
Faulted in DDB; continuing...
ddb{0}> x/x 0x7f826ae61000
0x7f826ae61000:uvm_fault(0xffffffff81da8270, 0x7f826ae61000, 0, 1) -> e
kernel: page fault trap, code=0
Faulted in DDB; continuing...
ddb{0}> x/x 0x7f826ae63000
0x7f826ae63000:uvm_fault(0xffffffff81da8270, 0x7f826ae63000, 0, 1) -> e
kernel: page fault trap, code=0
Faulted in DDB; continuing...
Note that /usr/src/regress/lib/libpthread/malloc_duel/malloc_duel.c
does allocations in small malloc(sizeof(int)) chunks. So I think
we are dealing with random page size mappings.
bluhm
