From owner-svn-src-user@freebsd.org Mon May 23 12:49:23 2016 Return-Path: Delivered-To: svn-src-user@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39004B462CB for ; Mon, 23 May 2016 12:49:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFA5E19DF; Mon, 23 May 2016 12:49:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u4NCnDku009002 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 23 May 2016 15:49:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4NCnDku009002 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4NCnDSd009001; Mon, 23 May 2016 15:49:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 May 2016 15:49:13 +0300 From: Konstantin Belousov To: Mark Johnston Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r300465 - user/alc/PQ_LAUNDRY/sys/vm Message-ID: <20160523124913.GU89104@kib.kiev.ua> References: <201605230528.u4N5S34B088158@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201605230528.u4N5S34B088158@repo.freebsd.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 12:49:23 -0000 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.