From owner-freebsd-arm@freebsd.org Fri Nov 13 17:10:05 2015 Return-Path: Delivered-To: freebsd-arm@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 6156BA2E0B2 for ; Fri, 13 Nov 2015 17:10:05 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC7341501 for ; Fri, 13 Nov 2015 17:10:04 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.200] (p508F1D2C.dip0.t-ipconnect.de [80.143.29.44]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1DC9A1C1C0209; Fri, 13 Nov 2015 18:10:01 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Memory management issue on RPi? From: Michael Tuexen In-Reply-To: Date: Fri, 13 Nov 2015 18:09:59 +0100 Cc: Konstantin Belousov , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <270ED040-C0C0-4D0E-9A7C-4D13F0368729@freebsd.org> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> <20151112180954.GP2257@kib.kiev.ua> <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> <20151112200300.GR2257@kib.kiev.ua> <6452F207-A79B-42C6-A2CC-07BF454B7024@freebsd.org> To: Warner Losh X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 17:10:05 -0000 > On 13 Nov 2015, at 16:12, Warner Losh wrote: >=20 >=20 >=20 > On Fri, Nov 13, 2015 at 1:23 AM, Michael Tuexen = wrote: > > On 12 Nov 2015, at 21:03, Konstantin Belousov = wrote: > > > > On Thu, Nov 12, 2015 at 08:47:29PM +0100, Michael Tuexen wrote: > >>> On 12 Nov 2015, at 19:09, Konstantin Belousov = wrote: > >>> > >>> On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: > >>>>> On 12 Nov 2015, at 18:12, Konstantin Belousov = wrote: > >>>>> > >>>>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > >>>>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov = wrote: > >>>>>>> This is a known problem with the swap-less OOM. The following = patch > >>>>>>> should give you an immediate relief. You might want to tweak > >>>>>>> sysctl vm.pageout_oom_seq if default value is not right, it = was selected > >>>>>>> by 'try and see' approach on very small (32 or 64MB) i386 VM. > >>>>>> It just works... Will do some more testing... > >>>>> > >>>>> I am more interested in report if OOM was triggered when it = should. > >>>> How do I know? What output do you want to see? > >>>> > >>>> Best regards > >>>> Michael > >>>>> > >>>>> Try running several instances of 'sort /dev/zero'. > >>> ^^^^^^^^^^^^^ I already answered this. > >>> Run sort /dev/zero, and see whether OOM fires. > >> OK, now I understand. You want to see if some processes are getting = killed. > >> (I was thinking that you might want to see some sysctl counters or = so). > >> > >> Results: > >> * I'm able to compile/link/install a kernel from source. This was = not > >> possible before. > >> * When running three instances of sort /dev/zero, two of them get = killed > >> after a while (less than a minute). One continued to run, but got = also > >> kill eventually. All via ssh login. > > Exactly, this is the experiment I want to occur, and even more, the = results > > are good. > Any plans to commit it? >=20 > These changes are good as an experiment. The RPi's relative speed of = the CPU > to the extremely slow SD card where pages are laundered to. Deferring = the calls > to the actual OOM a bit is useful. However, a simple count won't = self-scale. What's > good for the RPi likely is likely poor for a CPU connected to faster = storage. The OOM > won't kill things quickly enough in those circumstances. I imagine = that there may > be a more complicated relationship between the rate of page dirtying = and laundering. >=20 > I'd hope that there'd be some kind of scaling that would take this = variation into > account. >=20 > At Netflix, we're developing some patches to do more pro-active = laundering of pages > rather than waiting for the page daemon to kick in. We do this = primarily to avoid > flushing the uma caches which have performance implications that we = need to > address to smooth out the performance. Perhaps something like this = would be a > more general way to cope with this situation? I'm happy to test patches... Best regards Michael >=20 > Warner