Date: Mon, 23 May 2016 10:40:46 -0700 From: Mark Johnston <markj@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r300465 - user/alc/PQ_LAUNDRY/sys/vm Message-ID: <20160523174046.GB51657@wkstn-mjohnston.west.isilon.com> In-Reply-To: <20160523124913.GU89104@kib.kiev.ua> References: <201605230528.u4N5S34B088158@repo.freebsd.org> <20160523124913.GU89104@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 23, 2016 at 03:49:13PM +0300, Konstantin Belousov wrote: > On Mon, May 23, 2016 at 05:28:03AM +0000, Mark Johnston wrote: > > Author: markj > > Date: Mon May 23 05:28:03 2016 > > New Revision: 300465 > > URL: https://svnweb.freebsd.org/changeset/base/300465 > > > > Log: > > Address over-eager OOM kills. > > > > Prior to this change, vm_page_free_wakeup() and thus vm_page_free() would > > clear vm_pages_needed when the free page count is above v_free_min. If the > > pagedaemon is starved for pages to reclaim because of a runaway process or > > because all inactive pages are dirty, but other threads are occasionally > > freeing pages, and v_free_min <= v_free_count <= vm_pageout_wakeup_thresh, > > concurrent vm_page_free() and vm_page_alloc() calls will respectively clear > > and set vm_pages_needed, waking up the pagedaemon in the process. This can > > cause the domain's oom_seq value to increment very quickly, leading to a > > spurious OOM kill when the pagedaemon cannot find clean pages to reclaim in > > the time that it takes for some pages to be laundered. > > > > This can be triggered during multiple consecutive sysbench runs when it > > writes mmap'ed files that are larger than system memory. > > > > Fix the problem by modifying vm_page_free_wakeup() to only clear > > vm_pages_needed once v_free_count has risen above vm_pageout_wakeup_thresh. > > > > Reviewed by: alc > > > > Modified: > > user/alc/PQ_LAUNDRY/sys/vm/vm_page.c > > > > Modified: user/alc/PQ_LAUNDRY/sys/vm/vm_page.c > > ============================================================================== > > --- user/alc/PQ_LAUNDRY/sys/vm/vm_page.c Mon May 23 05:28:02 2016 (r300464) > > +++ user/alc/PQ_LAUNDRY/sys/vm/vm_page.c Mon May 23 05:28:03 2016 (r300465) > > @@ -2910,7 +2910,8 @@ vm_page_free_wakeup(void) > > * lots of memory. this process will swapin processes. > > */ > > if (vm_pages_needed && !vm_page_count_min()) { > > - vm_pages_needed = 0; > > + if (!vm_paging_needed()) > > + vm_pages_needed = 0; > > wakeup(&vm_cnt.v_free_count); > > } > > } > > I looked at this change for some time after you referenced it. Can this > occur on the stoxk HEAD ? At least I do not see why it cannot, from the > description. I agree - in principle this problem exists in HEAD as well. I haven't been able to trigger the spurious OOM kills there, but I also haven't spent much time trying to do so, and my test case will occasionally result in a low-memory deadlock on HEAD instead. In my test case, the pagedaemon would block while laundering pages (since the vnode pager's putpages operation is synchronous when memory is low), so I suspect that it is generally able to launder and free some pages before hitting the oom_seq threshold.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160523174046.GB51657>