From owner-freebsd-hackers@freebsd.org Wed Aug 5 23:59:33 2015 Return-Path: Delivered-To: freebsd-hackers@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 78E579B49D1 for ; Wed, 5 Aug 2015 23:59:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) by mx1.freebsd.org (Postfix) with SMTP id 5910635E for ; Wed, 5 Aug 2015 23:59:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 5 Aug 2015 23:59:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t75NxU1e021561; Wed, 5 Aug 2015 17:59:30 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1438819170.70393.227.camel@freebsd.org> Subject: Re: vm_lowmem is prevented every 2**31 ticks From: Ian Lepore To: Ryan Stone Cc: "freebsd-hackers@freebsd.org" Date: Wed, 05 Aug 2015 17:59:30 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 23:59:33 -0000 On Wed, 2015-08-05 at 19:48 -0400, Ryan Stone wrote: > Currently vm_pageout_scan() uses a calculation on ticks to rate-limit the > number of vm_lowmem() events. The calculation that it uses is: > > if (vmd == &vm_dom[0] && pass > 0 && > (ticks - lowmem_ticks) / hz >= lowmem_period) > > > The problem with this code is that there is no guarantee that > vm_pageout_scan() will be called with pass > 0 within any time period. > This can mean that (for example) lowmem_ticks could have been 0 an > arbitrarily long time ago, and if ticks happens to be negative when we are > running low on memory, the result of ticks - lowmem_ticks will be negative > and the condition will not be true until ticks goes positive again. > > A coworker suggested casting the result of the subtraction to a u_int. > This narrows the window considerably (down to 2 * lowmem_period seconds), > but it's not possible to eliminate the problem entirely as long as we use > ticks. I am tempted to just call getbintime() instead. Low memory events > should be infrequent enough that calling getbintime() should be ok. > > Unless somebody has an objection or an alternate solution, I'll put > together a patch using getbintime() and get that into phabricator. If you're measuring elapsed time, please use getbinuptime() rather than the time of day clock (which can be stepped arbitrarily). Hey wait a sec... if it's currently some_ticks/hz it's counting seconds, right? So no need to mess with bintimes, if whole seconds are good enough just use the global time_uptime. -- Ian