Date: Tue, 14 Aug 2018 00:09:42 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: John Kennedy <warlock@phouka.net>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <44459672-F494-4DE9-B055-A466BE3253C9@yahoo.com> In-Reply-To: <20180814014226.GA50013@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Aug-13, at 6:42 PM, bob prohaska <fbsd at www.zefox.net> wrote: > [Altered subject, philosophical question] > On Mon, Aug 13, 2018 at 01:05:38PM -0700, Mark Millard wrote: >> >> 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. >> [I'm not a FreeBSD designer and have never been one. The below notes suggest my guesses as to their choices for what to primarily target. But I do not plan on continuing for the "philosophical question".] > 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 following uses a very specific example of a rather different context from the tiny board computers. When I have access to the Ryzen Threadripper 1950X with 96 GiByte or 128 GiBytes of RAM installed I do not have this type of problem with -j32 (16 two-thread cores). (It has been a couple of months since I last did this.) No need to adjust vm.pageout_oom_seq . (In fact I was unaware of that control until recently.) In fact even for the 96 GiByte configuration I can poudriere bulk -a allowing 32 jobs that are reach allowed up to 32 active processes during the build of all the ports. The paging/swapping and "disk" I/O are fast and the RAM limits their use. (There are way over 20,000 ports that attempt to build when I do this. Frequently multiple tools chains build in significantly overlapping time frames, including multiple llvm's at once. If I remember right the build takes something like 36 hours, but it has been a fair time since I've run such a test.) [I'll note that the worst-case conditions of 32 jobs each actually using 32 active processes has never been closely approached when I've attempted this. But having hundreds of active processes at times does happen. But not hundreds of large-RAM-active-usage processes that each stay active over long periods.] It is an environment effectively designed for the type of activity, fitting FreeBSD's principles of operation, but scaled based on probabilities for the combinations of jobs that occur at once. (And it well covers buildworld buildkernel --which is primarily what I've used it for.) It is a very different environment from trying to get the the most out of a fairly minimal environment for the software involved. There is also a huge difference in cost. At least for now this 1950X context does not need "the" problem solved: it is not a problem so far. I.e, free RAM does not stay low for long so far. [Note: I'm not aware of any significant problem with a default of vm.pageout_oom_seq=120 or some such for the contexts that I deal with. But vm.pageout_oom_seq was added because an (implicit?) fixed figure was a problem before the addition. My earlier earlier text tries to generalize beyond the specifics for vm.pageout_oom_seq .] > The exact goals might vary, but coping with too much > to do and not enough to do it with is humanity's oldest puzzle. Trying to well span all the combinations without sometimes problematical tradeoffs is an unsolved problem. FreeBSD has picked what type of range it primarily targets and covers some other contexts in ways that fit with that. > 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 > > There's at least some degree of conflict between all of them, > made worse when the workload grows beyond the design assumptions. > The RPI makes the issue more visible, but it's always lurking. See above about the 1950X example: not always an active issue for the specific issue involved that this started from. > OOMA seems to sacrifice getting work done, potentially entirely, > in support of keeping the system responsive and under control. FreeBSD expects explicit management of the RAM use for whatever the general type of work is (such as using a smaller -jN for buildworld buildkernel --or vm.pageout_oom_seq assignment), and expects configurations designed to have the desired performance characteristics for the management technique used. (The two are not independent.) FreeBSD does not attempt to provide a universal, automatic management of RAM use that gets all potential forms of work done. FreeBSD is not designed to get maximal results from minimal hardware without explicit management, so: not automatic. > To have some fun with the office analogy, when business is > slow the clerk serves customers as they come in. When things > get busy, the clerk says "take a number". When they get really > busy new customers are told "come back tomorrow" and when they > get absolutely frantic present customers are told "I can't finish > this now, I'll call you when it's done". That's grace under pressure. Can you imagine types of computer-server contexts were such latency additions to much/most/all new incoming work is not acceptable? Where having some "failed try again"s for just some specific work examples would be better than adding notable latency to all the incoming work when things are not going well? Is everything having to wait to sometime later, such as the next day, or even far less time, called "server down" in some contexts, even if the OS on the server is still running? [I'm not claiming the existing Low Free RAM process-killer behavior is a direct solution. But it does can avoid swapping latencies automatically being involved.] (My activities are not in such server contexts but FreeBSD does not target my activities.) > What do FreeBSD's designers want the system to do as it's > progressively overworked? Is the office analogy too ambitious? > My earlier text suggests some of my expectations for this, but I can not speak for the historical or modern FreeBSD designers. They would have to confirm or deny various of my expectations and provide points I've not even considered. === Mark Millard marklmi at yahoo.com ( 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?44459672-F494-4DE9-B055-A466BE3253C9>