From owner-freebsd-arm@freebsd.org Fri Nov 13 15:12: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 A14F5A2E35B for ; Fri, 13 Nov 2015 15:12:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49E0F1C99 for ; Fri, 13 Nov 2015 15:12:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkfo3 with SMTP id o3so49643301qkf.1 for ; Fri, 13 Nov 2015 07:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PDxJr3mwNuQrdrMocWfbbcuAubpjH8+flhQMZ5fgckk=; b=hM73cUiXyWH292jQzu8jIHwbwVOumCpuHXUJ5Im5Z/y15MEy7GEfAgssd2sVw/Qcka 2jIJn6rtUhiDDacllGWMGqs3NGSGu4uDD7+8SAmEvk3PgS64CnL1wY+P7LCJ+ji7ZBZL jd3iQju7lNSioIAzjWqSFL1RhMfLDYFvOpKI8nDFHwGETw5EDv+qRw9TOQHW8YEMYBv6 1jKpkrRv+eHLmtAvJe7KCAHwAXLE/eumW/DcQfj+GzDCH2hvULTq8CGF+C+jqEnCGOew uRArJVCPoS7fH/Wvw0nVJh8ebZE0DAPg2RLdV+UrwgE5u2bfsOENLqAd6JTay/VQu8nv slAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PDxJr3mwNuQrdrMocWfbbcuAubpjH8+flhQMZ5fgckk=; b=T52GjwXsGuJlx3LrVOjJEViZHH784Pxyp5GLtu/MScwqn/psyZnTbzwdjalKQFweF/ yKzRvvPdY2HIi4WVWbfy0B1f37w3W3Pm0H1BoJse/Z3yizu3myMNFn1L8MoRANvLmXVM HLYPGQMRSRxnfT/7TE1UM+sGP3qxoErDT/GnUN/SQjxWWR26dXUOIUVzysn/9k5pELOs t5tDGDkJy54elK0mPOsrUMQyeP5cskBWYX3/OZ1cje6fnR84/IkEa8kRyZDiFScWBv/A tSTqRRhgYKzC5RJenrwrXPuWSZytluBNCAafifBmU3fiYtqbol/yVXpRRsU590j+OVb7 1NPQ== X-Gm-Message-State: ALoCoQl3i+CELha+hT3pPOJ6n8lGCK3KLE8OaPXaaMdC8p0ifKjW39a5JumFMs1FqtHLJsDQ5yaH MIME-Version: 1.0 X-Received: by 10.140.196.69 with SMTP id r66mr8025575qha.40.1447427524472; Fri, 13 Nov 2015 07:12:04 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Fri, 13 Nov 2015 07:12:04 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <6452F207-A79B-42C6-A2CC-07BF454B7024@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> Date: Fri, 13 Nov 2015 08:12:04 -0700 X-Google-Sender-Auth: Uh5o1JRlORqdutgAw6GahxI9kKI Message-ID: Subject: Re: Memory management issue on RPi? From: Warner Losh To: Michael Tuexen Cc: Konstantin Belousov , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 15:12:05 -0000 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? > 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. I'd hope that there'd be some kind of scaling that would take this variation into account. 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? Warner