svn commit: r300465 - user/alc/PQ_LAUNDRY/sys/vm

[Konstantin Belousov]

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.