From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 22:32:20 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BDE0FD7; Wed, 27 Mar 2013 22:32:20 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id BA14977B; Wed, 27 Mar 2013 22:32:19 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id d17so1035919eek.11 for ; Wed, 27 Mar 2013 15:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=trCb8Bk46mAXZWhQtKKr1naJfbEYtv7ZQVV24aSc2+o=; b=dknBOfb6cOr/vRzPU5W+KEgVkp5DkBN2ZDgeKneDNusKBhiq8oTSgAf+FG0clZHTSA LfptC+iyrS1MXVdjbfj79EMX2kUIi93i9MYTIh0d8Q+WpLdJ8R9H/C+D1yWv8a/TOZru 1ZmJl8v6ixmJpQCZKdFBzuMe4a7vVBVSyWw4vuSmlQ49otGt7o31CcSdjyQwsFU4kZqO 8i55j2szT0hS0cNWvBAGXpUvtmHaObJKq7NBEiIo3rremkB+NX4sXeK5ysNeUWCt2vZq K4+U/TaXUgekVLus9Dstx7s2iIAKkxMYfL/tbHlvohbwPFP3+sqL3GmqDB71uPef2qs9 T0eA== MIME-Version: 1.0 X-Received: by 10.15.22.76 with SMTP id e52mr51992429eeu.7.1364423532864; Wed, 27 Mar 2013 15:32:12 -0700 (PDT) Received: by 10.223.127.134 with HTTP; Wed, 27 Mar 2013 15:32:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Mar 2013 17:32:12 -0500 Message-ID: Subject: Re: [RFC] small VM patch to review From: Alan Cox To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 22:32:20 -0000 On Wed, Mar 20, 2013 at 12:24 PM, Maksim Yevmenkin wrote: > hello, > > would anyone object to the following small patch? > > Yes, I don't think that we should entirely disable vm_lowmem events or uma_reclaim() on pass == 0 calls to vm_pageout_scan(). However, I do think it's reasonable to significantly reduce the frequency at which we do both. My recollection is that UMA only releases idle pages from zones when uma_reclaim() is called. In other words, there is no mechanism like a high water mark on the number of idle pages in a zone that triggers the return of some of these idle pages to the VM system. Given this, turning off vm_lowmem events or uma_reclaim() calls on pass == 0 is fine for machines under a steady-state workload. But, if there are changes in the workload then we won't adapt our overall memory allocation to the new workload. Specifically, the loser would be the file cache/inactive queue, because even under moderate memory pressure we typically meet our goals on pass 0 by reclaiming file cache/inactive queue pages. So, instead of repurposing unused pages from UMA to the file cache/inactive queue, we would leave them lingering in UMA. (Also note I've not said anything about the ZFS ARC, because I'm not exactly sure how it uses the vm_lowmem events. This may or may not be a problem. I don't know.) > == > > Index: vm_pageout.c > =================================================================== > --- vm_pageout.c (revision 248560) > +++ vm_pageout.c (working copy) > @@ -882,14 +882,17 @@ > > vm_pageout_init_marker(&marker, PQ_INACTIVE); > > - /* > - * Decrease registered cache sizes. > - */ > - EVENTHANDLER_INVOKE(vm_lowmem, 0); > - /* > - * We do this explicitly after the caches have been drained above. > - */ > - uma_reclaim(); > + if (pass) { > + /* > + * Decrease registered cache sizes. > + */ > + EVENTHANDLER_INVOKE(vm_lowmem, 0); > + /* > + * We do this explicitly after the caches have > + * been drained above. > + */ > + uma_reclaim(); > + } > > /* > * The addl_page_shortage is the number of temporarily > > == > > the idea is to not invoke lowmem handler etc. on first pass in > vm_pageout_scan(). it saves a few CPU cycles on a relatively busy > webserver with moderate amount of RAM serving large-ish files. > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >