Unkillable process in "vm map (user)"

[Peter Holm]

On Fri, Dec 22, 2017 at 02:45:21PM +0200, Konstantin Belousov wrote:
> On Fri, Dec 22, 2017 at 10:26:07AM +0100, Peter Holm wrote:
> > Here's some more info, using the original scenario:
> > https://people.freebsd.org/~pho/stress/log/kostik1070.txt
> 
> This is somewhat weird but also not too puzzling.
> 
> The vmdaemon (pid 41) is running, it tries to reduce the count of resident
> pages in some pmap, most likely the one from the pid 20655.  This process
> seems to be huge: according to the v_stats, there is 15681264 inactive pages,
> and the pagedaemon tries to obtain a vm object lock which is owned by
> vmdaemon, resident count for that object is 15897170 (~64Gb).
> 
> So basically almost all memory belongs to the single object and vmdaemon
> processing it.  Since the object' queue is huge, the map and the object
> locks are taken for long time, preventing other processes touching them
> from making a progress.
> 
> Might be try this (it combines new changes with the OOM patch). I am not
> sure that should_yield() in the vm_swapout_object_deactivate_pages() is
> a good idea unconditionally, but it might be better than the current
> situation.
> 
> diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c
> index ece496407c2..ce6208569c6 100644
> --- a/sys/vm/vm_fault.c

The patch fixes the problem I got with this scenario.

- Peter