Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Nov 2015 18:09:59 +0100
From:      Michael Tuexen <tuexen@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: Memory management issue on RPi?
Message-ID:  <270ED040-C0C0-4D0E-9A7C-4D13F0368729@freebsd.org>
In-Reply-To: <CANCZdfqibervY41hfSj1aVmScJUfzAz-K5A-7wRQs_xzZoJ6cQ@mail.gmail.com>
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> <CANCZdfqibervY41hfSj1aVmScJUfzAz-K5A-7wRQs_xzZoJ6cQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 13 Nov 2015, at 16:12, Warner Losh <imp@bsdimp.com> wrote:
>=20
>=20
>=20
> 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?
>=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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?270ED040-C0C0-4D0E-9A7C-4D13F0368729>