>> The problem seems related to certain long running processes with >> fragmented address spaces. >> >> Basically, in order to manage address spaces, the kernel keeps track >> of a bunch of maps. Entries in these maps are stored in... map >> entries. In certain situations, the kernel can't wait to allocate a >> map entry, so it grabs one from a static list. Previously, when they >> ran out, the kernel paniced. Now it just says uh oh. The kernel will >> merrily go on making more static entries as needed. > > the problem is not in the user land. > the problem is in i386 pmap which abuses kmem_map that is there > for malloc(9)s use and allocates pv_entries from it. > this leads to enormous kmem_map fragmentation and unaccounted > allocations that does not show up in the vmstat and as well leads > to livelocks (sleeping on kmem_map) and out of space in kmem_map > panics as well. there is a number of measures to remediate the > situation proper > - convert pv_entries allocations to pool (i have a diff if you wanna) Yes, please. Definitely... and thanks.
FWIW I can bring a spare server online this weekend to keep in the wings in case something goes completely nutty with the diff, so no worries about this affecting production per se. :-) Is the diff against 4.3 or 4.3-current? > - backend malloc w/ pool (filed in sendbug) > - a number of uvm fixes (such as amap ops) that reduce fragmentation.
