From owner-freebsd-arm@freebsd.org Tue Jul 31 19:10:02 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3535106234C for ; Tue, 31 Jul 2018 19:10:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 166B5780A5 for ; Tue, 31 Jul 2018 19:10:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w6VJAHrt095359 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Jul 2018 12:10:18 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w6VJAHqK095358; Tue, 31 Jul 2018 12:10:17 -0700 (PDT) (envelope-from fbsd) Date: Tue, 31 Jul 2018 12:10:16 -0700 From: bob prohaska To: "Rodney W. Grimes" Cc: bob prohaska , freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments Message-ID: <20180731191016.GD94742@www.zefox.net> References: <20180731153531.GA94742@www.zefox.net> <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201807311602.w6VG2xcN072497@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 19:10:02 -0000 On Tue, Jul 31, 2018 at 09:02:59AM -0700, Rodney W. Grimes wrote: > > An easy way of triggering OOM that I ran accross the other day is simply: > truncate -s 4G foo > grep Anything foo > > grep(1) well gladly grow up to 4G trying to create a "line" of text > to search for the string "Anything". On a system with less than > 4G of free memory this triggers an OOM and starts killing processes. > If grep actually uses 4GB before OOMA kills it then maybe OOMA is working correctly. Naive reasoning wonders why it would take that much memory to find an eight-character string, but that's not germane here. Unless, of course, buildworld is using grep in a similar way. What I'm seeing is OOMA kills that happen when swap usage is low, swap paritions don't seem overwhelmingly busy and read write delays are far less than maximums observed for the session. One possibility is that my gstat logs are not accurate measurements of storage activity. The logging script is #!/bin/sh while true do gstat -abd -I 10s ; date ; swapinfo ; tail -n 2 /var/log/messages done Does the script contain errors or omissions? In the most recent case the worst delays were 15 seconds for read and 38 seconds for write, OOMA didn't act until two hours later, when swap usage was only about 130 MB and write delay to swap was 135 ms. That's what tempts me to think the kills are an artifact of some other behavior. This is why I'd like to see what happens if OOMA could simply be turned off or its trigger level adjusted. On a Pi, bogging down for a few minutes during a buildworld session is perfectly ok. I appreciate that an e-commerce server or cloud computing system is a different kettle of fish entirely. Some weeks (months?) ago there was a thread about swap being broken. Was that in any way related to what I'm seeing? Thanks for reading! bob prohaska