Date: Tue, 14 Aug 2018 17:33:37 -0700 From: Mark Millard <marklmi@yahoo.com> To: Warner Losh <imp@bsdimp.com> Cc: bob prohaska <fbsd@www.zefox.net>, freebsd-arm <freebsd-arm@freebsd.org>, Mark Johnston <markj@freebsd.org> Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <D7D7478B-613E-43EB-9655-054CB6FD9578@yahoo.com> In-Reply-To: <CANCZdfqFKY3Woa%2B9pVS5hika_JUAUCxAvLznSS4gaLq2kKoWtQ@mail.gmail.com> References: <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <B81E53A9-459E-4489-883B-24175B87D049@yahoo.com> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <FC0798A1-C805-4096-9EB1-15E3F854F729@yahoo.com> <20180813185350.GA47132@www.zefox.net> <FA3B8541-73E0-4796-B2AB-D55CE40B9654@yahoo.com> <20180814014226.GA50013@www.zefox.net> <CANCZdfqFKY3Woa%2B9pVS5hika_JUAUCxAvLznSS4gaLq2kKoWtQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Aug-14, at 4:50 PM, Warner Losh <imp at bsdimp.com> wrote: > On Mon, Aug 13, 2018 at 7:42 PM, bob prohaska <fbsd@www.zefox.net = <mailto:fbsd@www.zefox.net>> wrote: > [Altered subject, philosophical question] > On Mon, Aug 13, 2018 at 01:05:38PM -0700, Mark Millard wrote: > >=20 > > Here there is architecture choice and goals/primary > > contexts. FreeBSD is never likely to primarily target > > anything with a workload like buildworld buildkernel > > on hardware like rpi3's and rpi2 V1.1's and > > Pine64+ 2GB's and so on. > >=20 >=20 > I understand that the RPi isn't a primary platform for FreeBSD. > But, decent performance under overload seems like a universal > problem that's always worth solving, whether for a computer or > an office. The exact goals might vary, but coping with too much > to do and not enough to do it with is humanity's oldest puzzle.=20 >=20 > Maybe I should ask what the goals of the OOMA process serve. > I always thought an OS's goals were along the lines of: > 1. maintain control > 2. get the work done > 3. remain responsive >=20 > Simplistically, one can view the VM system as a producer of dirty = pages, and a cleaner of dirty pages. These happen at different rates, = but usually are closely matched. We're normally able to launder enough = pages to satisfy the need for new pages from the VM system (since clean = pages can just be thrown away w/o any loss of data). The problem happens = when we put a large load onto the creation side with a build. This = generates a lot of dirty pages, and we have to flush the writes of the = dirty pages quickly to keep up. When the backing store has time-varying = write rates that vary substantially, we run into problems. Just an FYI example comparison/contrast: For a buildworld buildkernel example with vm.pageout_oom_seq=3D12 v_free_count: 7773, v_inactive_count: 1 Aug 12 09:30:13 pine64 kernel: pid 80573 (c++), uid 0, was killed: out = of swap space without any "Mark J." messages such as: waited 4s for async swap write waited 4s for swap buffer waited 4s for async swap write waited 4s for async swap write waited 4s for async swap write The code uses 3s as the starting point for such reports as I remember, so shorter times would not have been reported. The context was a Pine64+ 2GB. A from-scratch buildworld buildkernel with vm.pageout_oom_seq=3D120 also reported no "waited" messages but had no kills. Note: I got that little "4s" block during a later poudriere bulk during or a few seconds after the devel/cmake build. So far that is the only report that I've seen from Mark J.'s reporting code for the Pine64+ 2G context that I have access to. Not even the later about 14.5 hr devel/llvm60 build reported such messages. poudreire bulk was running one job at a time but allowed each job to use all 4 cores. > . . . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net <http://dsl-only.net/>; went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D7D7478B-613E-43EB-9655-054CB6FD9578>