Date: Fri, 22 Dec 2017 16:35:53 +0100 From: Peter Holm <peter@holm.cc> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Peter Jeremy <peter@rulingia.com>, freebsd-stable@freebsd.org Subject: Re: Unkillable process in "vm map (user)" Message-ID: <20171222153553.GA41052@x2.osted.lan> In-Reply-To: <20171222124521.GR12785@kib.kiev.ua> References: <20171210200931.GS23931@server.rulingia.com> <20171210204217.GC2272@kib.kiev.ua> <20171222092607.GA35523@x2.osted.lan> <20171222124521.GR12785@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171222153553.GA41052>