Date: Fri, 13 Nov 2015 08:12:04 -0700 From: Warner Losh <imp@bsdimp.com> To: Michael Tuexen <tuexen@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Memory management issue on RPi? Message-ID: <CANCZdfqibervY41hfSj1aVmScJUfzAz-K5A-7wRQs_xzZoJ6cQ@mail.gmail.com> In-Reply-To: <6452F207-A79B-42C6-A2CC-07BF454B7024@freebsd.org> References: <CB20D8FA-303C-4AA2-B2A6-1FF25DDB8A94@freebsd.org> <20151112121825.GJ2257@kib.kiev.ua> <BE0B4761-54EC-4632-BA23-A3C373D419AE@freebsd.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 13, 2015 at 1:23 AM, Michael Tuexen <tuexen@freebsd.org> wrote: > > On 12 Nov 2015, at 21:03, Konstantin Belousov <kostikbel@gmail.com> > wrote: > > > > On Thu, Nov 12, 2015 at 08:47:29PM +0100, Michael Tuexen wrote: > >>> On 12 Nov 2015, at 19:09, Konstantin Belousov <kostikbel@gmail.com> > wrote: > >>> > >>> On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: > >>>>> On 12 Nov 2015, at 18:12, Konstantin Belousov <kostikbel@gmail.com> > wrote: > >>>>> > >>>>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > >>>>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov <kostikbel@gmail.com> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqibervY41hfSj1aVmScJUfzAz-K5A-7wRQs_xzZoJ6cQ>