Date: Tue, 14 Aug 2018 17:56:20 +1000 From: Patrick Crilly <pcrilly@goodgas.com.au> To: freebsd-arm@freebsd.org Subject: Re: RPI3 swap experiments (grace under pressure) Message-ID: <02fe39af-a02c-fb6a-70b0-da3b7fd06c22@goodgas.com.au> 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 14-Aug-18 11:42 AM, bob prohaska 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 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. It's a very difficult problem to solve. And provokes some pretty heated arguments. If you are experiencing overload, then there's a case for saying the platform/system isup to the task. > > 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. > > OOMA seems to sacrifice getting work done, potentially entirely, > in support of keeping the system responsive and under control. I believe the thinking is that if the system remains remains responsive you have a chance of fixing the problem or at the very least you can login and gather information about what is causing the problem. > > 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. Nice analogy. If people just keep coming all day, I think what you've described is a responsive system. The clerk isn't getting any work done, he's just responding to customers. And would "can't finish it now" be analogous to killing off processes? > What do FreeBSD's designers want the system to do as it's > progressively overworked? Is the office analogy too ambitious? > > Thanks for reading, and apologies for the ruminating. > -- "With great power comes great electricity bill"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02fe39af-a02c-fb6a-70b0-da3b7fd06c22>